On Thu, May 21, 2009 at 2:46 PM, Steve Prentice <prent...@cisco.com> wrote: > On May 21, 2009, at 10:52 AM, Tom Lane wrote: >> >> It's probably time to bite the bullet and redo the parser as has been >> suggested in the past, ie fix things so that the main parser is used. >> Ideally I'd like to switch the name resolution priority to be more >> Oracle-like, but even if we don't do that it would be a great >> improvement to have actual syntactic knowledge behind the lookups. > > That kind of refactoring is beyond my experience-level with the code, but I > can't say I disagree with your analysis. > >> Just for the record, you'd have to put the same kluge into the T_RECORD >> and T_ROW cases if we wanted to do it like this. > > Patch updated.
I played around a bit with the latest version of this patch tonight, but I'm replying to this previous version for the sake of being able to quote more of the relevant discussion. First, I applied this patch, which resulted in a successful compile, but PL/pgsql wouldn't load. After scratching my head for a minute, I recalled that this was supposed to be dependent on named and mixed notation, so I applied both patches, which resulted in a failed compile. Further experimentation revealed that named and mixed notation alone also lead to a failed compile. I replied to the named/mixed notation thread so hopefully Pavel will fix whatever the problem is with that patch. However... even assuming I can get this to work at all, it seems like it's only going to help in a pretty limited range of cases. Since this is just looking for occurrences of "AS", it has a chance of working (of course I can't test at the moment) for something like this: select foo as bar from generate_series(1,10) foo; ...but I think it will certainly fail for something like this: select foo bar from generate_series(1,10) foo; As much as I'm annoyed by the stupidity of PL/pgsql in this regard (and I really am - I use it constantly and this is a real pain in the neck), I think it makes more sense to wait for a more comprehensive solution. Also, besides the fact that this doesn't (and can't) handle all cases, as Tom points out, this would create a real possibility that some future use of the word AS could cause breakage at a distance. So, I guess I'm sadly left feeling that we should probably reject this patch. Anyone want to argue otherwise? ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
