Re: automatic parser generation for ecpg

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: automatic parser generation for ecpg
Дата
Msg-id 18633.1224594613@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: automatic parser generation for ecpg  (Mike Aubury <mike.aubury@aubit.com>)
Ответы Re: automatic parser generation for ecpg  (Michael Meskes <meskes@postgresql.org>)
Список pgsql-hackers
Mike Aubury <mike.aubury@aubit.com> writes:
> In reality - it doesn't look too disimilar from the awk original. I didn't 
> appreciate that we'd probably need to keep 2 versions (one for unix and one 
> for windows). In that case - I'd argue that we only need to "maintain" one 
> and regenerate the other when required. Provided they both work the same, I'd 
> say it doesn't matter what the perl one looked like, because thats not the 
> one that'd be maintained :-)

That'd only be acceptable if the code conversion were fully automatic
--- given your reference to "tweaks" I wasn't sure if that could be the
case.

> Personally - I'd be tempted to keep this as a background process for
> the ecpg maintiner anyway rather than a normal end user.

While we could approach it that way, it doesn't really meet all the
goals I was hoping for.  The current process is unsatisfactory for at
least two reasons above and beyond "Michael has to do a lot of
gruntwork":

* People hacking on the core grammar might break ecpg without realizing
it.  They need short-term feedback from the standard build process,
or at the worst from the standard buildfarm checks.

* For the last little while, changing the core keyword set breaks ecpg
completely, which means we have the worst of all possible worlds: core
modifiers have to hack ecpg to get it to compile, and then Michael has
to do more work to get it to actually work right.

I've been willing to put up with the second problem because I expected
the ecpg grammar build process to become fully automatic soon.  If that
doesn't happen then I'm going to be lobbying to revert the change that
made ecpg depend directly on the core keyword set.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pg_stat_statements in core
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: minimal update