Notation for nextval() (was Re: Several small patches)

[ Note redirection to hackers list ]

Peter Eisentraut <peter_e@gmx.net> writes:
>> It should actually almost work to write sq.nextval as things stand,
>> because Postgres has for a long time considered table.function and
>> function(table) to be interchangeable notations for certain kinds of

> May I wonder what the point and value of that practice is and why one
> would want to extend it further?

I think the reason the Berkeley guys did it originally was to support
functions that return tuples, and in particular extracting individual
columns of such a function's result.  They didn't want to allow
function(sourcetable).column

(for reasons not real clear to me, but maybe they had good ones),
so they wrote it as
sourcetable.function.column

This actually still works; you can find examples in the regress tests.

My first reaction to Jeroen's patch was that it was a good idea poorly
implemented.  I've never liked nextval('sequenceobject') from a
syntactic point of view, because a quoted string isn't an identifier
but you really want to have a normal SQL identifier to name the sequence.
(For example, right now we have some truly ugly hacks to try to make
that constant behave like a regular identifier as far as
case-folding-or-not-case-folding goes.)

It'd be a lot nicer if the syntax could be just nextval(sequencename)
or sequencename.nextval.  And since you can select parameters of the
sequence with sequencename.field, why shouldn't sequencename.nextval
work?

However, on second thought I wonder if we'd be opening a can of worms
to do it that way.  If I write
SELECT a, foo.b FROM bar;

what I actually get is a join across tables foo and bar --- foo is
implicitly added to the FROM list.  Now, if I were to write
SELECT a, foo.nextval FROM bar;

presumably I don't want a join against the sequence foo, but I am not
sure that this will be clear either to a human reader or to the machine.
And if you think that's clear enough, what about
SELECT a, foo.nextval, foo.min_value FROM bar;

which surely *must* cause a true join to be generated, since min_value
is a perfectly ordinary field of foo?

So now I'm worried that making the sequence object visible as a table
identifier will cause strange misbehaviors, or at least great confusion.
This needs careful thought before we can accept it.
        regards, tom lane