Alvaro Herrera <alvhe...@commandprompt.com> writes:
> Alvaro Herrera wrote:
>> I noticed that if you start from a clean tree, it doesn't work to build
>> pg_dump because gram.h has not been generated yet:
> This patch fixes it.
I think this is probably going in the wrong direction. The reason
gram.h isn't already in the main include tree is that we don't *want*
all and sundry depending on it --- we have very carefully minimized
the number of files that depend on the grammar's symbol codes.
ISTM that pg_dump doesn't actually care about the symbol codes, it
just needs a list of known keywords. Can we refactor things so that
the frontend-side version of the keyword list doesn't include the
grammar symbols at all?
One idea that comes to mind is to replace the entries like
{"abort", ABORT_P, UNRESERVED_KEYWORD},
with macro calls
PG_KEYWORD("abort", ABORT_P, UNRESERVED_KEYWORD),
and then the frontend build of the file could define the macro
to ignore its second argument.
The way we do it now seems to have other disadvantages too: we are
incorporating a backend .o file into pg_dump as-is, which would lead
to large problems if there were differences in say the compiler flags
needed. In fact, I thought Zdenek had been working on decoupling
that sort of thing, so I'm a bit surprised it's still like this at all.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
