Thread: Operators and Functions

I was starting to update the chapter on operators in the User's Guide but
when I arrived at the LIKE operator/function it occurred to me that the
division between functions and operators is quite unnatural.

ISTM that someone reading the User's Guide is primarily interested in
solving a problem, like "How do I mangle my text strings?", and doesn't
necessarily care whether the answer is implemented as an operator or a
function.

I'd envision merging the information into one chapter with the following
outline:

Functions and Operators
    Comparison
        (>, <, <>, etc.)
    Arithmetic and Trigonometry
        (+, -, abs, sin, ...)
    Character string manipulation
        (||, trim, repeat, length, etc.)
    Pattern matching
        (LIKE, ~)
    Formatting
        (to_char, ...)
    Date/Time
    Geometry
    Network Address Type Functions and Operators
    Special Conditionals
        (COALESCE, NULLIF, CASE)
    Miscellaneous
        (CURRENT_USER, SESSION_USER)
    Aggregate Functions

Lexical precedence would move into the "SQL Syntax" chapter.

Comments?

--
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/

Peter Eisentraut <peter_e@gmx.net> writes:
> ... the division between functions and operators is quite unnatural.

Agreed --- especially seeing as how every operator has an underlying
function.

> I'd envision merging the information into one chapter with the following
> outline:

Seems reasonable to me.

BTW, this may be more work than you want to do right now, but ISTM that
the "example" columns in those tables would be lots more useful if the
result of the example were shown too.  I did that for the network
functions already, but haven't got round to working on the rest.

            regards, tom lane

> I'd envision merging the information into one chapter with the following
> outline:

All good. Btw, what would you suggest wrt listing you as (an? the?) docs
editor for this release?

                    - Thomas

Thomas Lockhart writes:

> All good. Btw, what would you suggest wrt listing you as (an? the?) docs
> editor for this release?

I think an <authorgroup>PostgreSQL Global Development Group</> plus a few
acknowledgements where other sources have been used is enough for our
purposes.  We generally don't identify the release engineer separately
either.

--
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/