From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Upgrading our minimum required flex version for 8.5 |
Date: | 2009-07-12 15:05:35 |
Message-ID: | 162867790907120805u62086a3eve6006d9b9c3b36c2@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2009/7/12 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
>> 2009/7/12 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>>> If we're going to go for reentrancy
>>> I think we should fix both components.
>
>> when we don't use reentrant grammar, then we cannot use main sql parser in SQL?
>
> It wouldn't be a problem for the immediate application I have in mind,
> which is to re-use the core lexer in plpgsql. But it does seem like
> it might be a problem down the road as plpgsql gets smarter.
>
it's bad. I thing so integration main parser into plpgsql should be
the most important feature of plpgsql from trapping exception time. I
have to ask - we need it necessary reetrant grammer? We need
integration only in complilation time - for CREATE FUNCTION statement.
Can be nonreetrant grammer problem (but we have to store some info
from validation time somewhere - maybe in probin column) ?
> regards, tom lane
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-07-12 15:17:04 | Re: concurrent index builds unneeded lock? |
Previous Message | Tom Lane | 2009-07-12 15:02:32 | Re: *_collapse_limit, geqo_threshold |