Re: Notation for nextval() (was Re: Several small patches)
От | Jeroen van Vianen |
---|---|
Тема | Re: Notation for nextval() (was Re: Several small patches) |
Дата | |
Msg-id | 4.2.0.58.19991217060920.0096d500@mail.design.nl обсуждение исходный текст |
Ответ на | Notation for nextval() (was Re: Several small patches) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Re: Notation for nextval() (was Re: Several small patches)
(Bruce Momjian <pgman@candle.pha.pa.us>)
Re: [HACKERS] Re: Notation for nextval() (was Re: Several small patches) (Tom Lane <tgl@sss.pgh.pa.us>) Re: [HACKERS] Re: Notation for nextval() (was Re: Several small patches) (Tom Lane <tgl@sss.pgh.pa.us>) Re: Notation for nextval() (was Re: Several small patches) (Peter Eisentraut <peter_e@gmx.net>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления:
Следующее
От: Bruce MomjianДата:
Сообщение: Re: [HACKERS] Re: Notation for nextval() (was Re: Several small patches)