Postgres Pro
Downloads
Home   >   mailing lists

Thread: Documentation for alternate names of functions

Documentation for alternate names of functions

From
Daniel Cory
Date:

Can we document that “pow” is the same as “power”? It is not listed on https://www.postgresql.org/docs/current/static/functions-math.html, even though both “ceil” and “ceiling” are listed.

 

Can we document “int4larger” and related functions? They are similar to the greatest/least functions but not listed on https://www.postgresql.org/docs/current/static/functions-conditional.html#FUNCTIONS-GREATEST-LEAST

 

Thanks,

Dan

Re: Documentation for alternate names of functions

From
"David G. Johnston"
Date:
On Tue, Sep 4, 2018 at 2:17 PM, Daniel Cory <dcory@tableau.com> wrote:

Can we document that “pow” is the same as “power”? It is not listed on https://www.postgresql.org/docs/current/static/functions-math.html, even though both “ceil” and “ceiling” are listed.

For aliased function names for which only one is SQL standard we should denote which one.  This particular alias seems worthy of inclusion.
 

 

Can we document “int4larger” and related functions? They are similar to the greatest/least functions but not listed on https://www.postgresql.org/docs/current/static/functions-conditional.html#FUNCTIONS-GREATEST-LEAST


I don't see the point of exposing this implementation detail when the greatest/least expressions (i.e., they don't appear under \df), though non-standard, are what users are encouraged to use.  Not sure we'd turn down a patch but its not something I'd expect to get picked up in a timely fashion.

David J.

Re: Documentation for alternate names of functions

From
Tom Lane
Date:
Daniel Cory <dcory@tableau.com> writes:
> Can we document that "pow" is the same as "power"?

Meh.  power() is the SQL-standard spelling; I don't see a good reason to
encourage people to use the legacy name.  We might hope to get rid of
that name someday (cf commit fc7fd5018).

> Can we document "int4larger" and related functions?

We intentionally do *not* document functions that are only meant to be
used as infrastructure for operators and aggregates.  If we did, the
tables would be far larger and would just encourage people to use
functions we'd prefer they didn't.  As with the pow() case, this'd
basically be enlarging our exposed surface of frozen API, and I don't
think that's desirable.

            regards, tom lane