From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: building pg_dump doesn't work |
Date: | 2009-03-03 21:55:18 |
Message-ID: | 17291.1236117318@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-03-03 22:08:00 | We will do releases soon because of bug #4680; please help test |
Previous Message | Alvaro Herrera | 2009-03-03 21:18:28 | Re: building pg_dump doesn't work |