Re: [HACKERS] Re: Notation for nextval() (was Re: Several small patches)

OK, I have read this. Please give me reasons for any patches you
supply. I would be glad to apply the patch you needed to get psql to
compile if you sent it to me again. I had no idea why the change was
being made. Same for the copyright change.

> At 20:19 16-12-99 -0500, Tom Lane wrote:
> >Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)gmx(dot)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
>
>
> ************
>

--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026