>> ok - I don't though about it. My goal is integration main parser next
>> commitfest, but it is true, so somebody would to play with named
>> params now. Commiting of Steve's patch doesn't break anything.
>
> I'm a little confused here. We are 19 days into a 31 day CommitFest;
> you are almost three weeks too late to add a patch to the queue.
> Unless you can convince a friendly committer to pick this up out of
> sequence, I think the only patch that is under consideration here is
> the one that has been being discussed on this thread for the last 17
> days. I sent several notes adding for all patches to be added to
> commitfest.postgresql.org prior to the start of CommitFest; AFAIK,
> this one was never added.
>
> You haven't actually specified which other patch of Steve's you're
> talking about anyway, but I'm guessing it's this one here:
> http://archives.postgresql.org/pgsql-hackers/2009-05/msg00801.php
>
> I don't think that patch would get applied even if HAD been added to
> the CommitFest page in time, see Tom's remarks here:
> http://archives.postgresql.org/pgsql-hackers/2009-05/msg00802.php
>
> Let's get back to focusing on the patch that is actually under
> consideration here.
>
There are two patches - named and mixed parameters and protecting "AS"
as keyword. First patch is pl independed, second patch is related to
plpgsql. Both patches was in queue and Bernard did reviewing both I
thing. Second patch fix some unwanted behave in plpgsql and it does on
level that was possible on code base one month old.
I hope, so we will be able to integrate main parser to core. I hope so
this will be in next commitfest. If we doesn't release code after this
commitfest, then I'll prefer wait for integration, but now, when we
will release code, I thing, so for somebody should be nice to use
fixed plpgsql.
I thing so Steve fixed issues mentioned by Tom
http://archives.postgresql.org/pgsql-hackers/2009-05/msg00804.php
Integration of main parser to plpgsql will be very significant change
and it needs separate patch. This solve some others big problems
plpgsql and I would to solve it separately.
I'll be glad to answer all questions.
Pavel
> ...Robert
>
