7

I noticed that has been made a synonym of . (Paul White♦, Sep 29 at 13:33, if I read https://dba.stackexchange.com/tags/synonyms correctly.

I am not too happy with this, since functions returning a set exhibit a family of problems distinct from plain functions and I would like to be able to search for that.

(currently also synonym of ) and (not there yet) could be synonyms of .

Do you agree?
If so, can the change be reverted? Or are original tags lost after the merge?

5

Ok:

No tag assignments were lost.

We can monitor the usage of these tags and revisit the situation after a period of time.

2

While I don't love it either, I do think that the functions tag works best as a broad tag.

As Evan alluded to, there are a ton of more specific versions (far more than the 4 listed) that could exist, but I think that it would be more confusing than helpful for many askers and most of them wouldn't get a lot of use.

So, I propose an alternative: built-in-function to refer to out of the box functions and user-defined-function to refer to custom functions. These would provide more clarity without resulting in too many permutations of function tag options. This would help categorize the general problem area of the question - how to use the DB feature functions properly/efficiently vs. custom coding help/errors.

It would be good, of course, to also tag the language in this scenario as well (and I guess any scenario).

  • 1
    I can't see user-defined as being useful, if it's user-defined you should just tag the language you're using to define it. (Just me though). Also, builtins change quite frequently (moving from non-builtins to builtins). Seems a bit problematic too. – Evan Carroll Jun 20 '18 at 22:46
  • @LowlyDBA I tend to agree that functions works best, but we'll see how it goes. – Paul White Jun 21 '18 at 5:28
-1

The function tag should be dissolved for being too broad. There are 10,000 ways to slice up. You've made an argument for one of them, I like it. My preference would be to ban the tag entirely and go with something like,

  • Window functions functions-window
  • Aggregate functions functions-aggregate
  • Table-Value Functions functions-table-valued
  • Scalar-Value Functions functions-scalar-valued

This defines the role of the function, and all tags should carry a mention to also tag the language you're using if you're writing a function, (tsql, c-sharp, perl, plpgsql) etc.

Generally, I like the PostgreSQL naming conventions and they're close to the spec. But the spec doesn't provide guidance for a break down. The terms scalar and table are used in Microsoft and IBM. "Scalar" is used in math and most every computer language

Why not Set-returning?

I don't know of anything else where we call something that can act as a table a "set", and it seems very likely to be confusing if actual SQL multisets are ever introduced in Pg, or in any db that has them.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .