On Thu, May 21, 2009 at 2:46 PM, Steve Prentice <prentice@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