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@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
> 
> 
> ************
> 


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