Re: building pg_dump doesn't work

Alvaro Herrera <alvherre(at)commandprompt(dot)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