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

At 20:19 16-12-99 -0500, Tom Lane wrote:
>Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Applied nextval patch.
>
>I'm still not happy with it --- it may be in a different place, but it
>still breaks regular tables that have "nextval" or "currval" columns,
>because foo.nextval is still transformed to nextval('foo') regardless
>of whether foo is a sequence or not.
>
>
>What I was hoping for was something that would *first* determine whether
>foo is a sequence and *then* do the transformation only if so.
>This is obviously not possible at the grammar level (the grammar doesn't
>know what kind of table foo is, if indeed foo is a table at all), but
>ParseFuncOrColumn does have enough info to inspect foo's type.

I thought about this, but couldn't figure out how to test for foo being a 
sequence.


>Now that I think about it, though, there are some potential semantic
>problems with the whole idea.  See my about-to-be-written response to
>Peter's comment.
>
> > I don't agree with the parts of the patch, and
> > did not apply them.
>
>I believe his patch to bin/psql/describe.c is reasonable.  Evidently
>he's dealing with a C compiler that tries to fold multi-part strings
>into one part during preprocessing, and it's getting confused by
>the conditional compilation of one line of the string.  His proposed
>fix is more readable than the original code anyway, IMHO.

Yes, I needed this to get psql to compile at all.

>I'm dubious about the other two patches also.  Evidently there is some
>variation across platforms in the desirable switches for ctags --- but
>diking out the ones not wanted on a particular platform is no answer.
>Perhaps the proper fix is to make the ctags flags a configurable
>macro...

The difference in the copyright notice patch is just extending the 1994 - 
1999 to 2000 and aligning the quotes.

About ctags: is no one using Linux and ctags on the Postgres sources? Am I 
the first one to find this bug?

At 20:35 16-12-99 -0500, Tom Lane wrote:
>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.

I didn't think about these complications at all (thought that my small 
patch would just add a little more compatibility with a minimum of fuss, 
but I was wrong). Let me investigate whether I can come up with a better 
solution.


Cheers,

Jeroen