Re: building pg_dump doesn't work

Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>
>> Hmm, I had thought that pg_dump only wanted the header file, not the
>> keywords.o object file. I now see that I was wrong. I agree that your
>> proposed solution is a lot better. I'll see about it.
>
> Here it is. The #ifdef parts seem a bit ugly, but I'm not sure how can
> this be improved, given that ECPG is already using this file.

Perhaps this could be made less ugly by only having the ScanKeywords
array in the .c file, and #including that into other .c files in
src/backend/parser, ecpg and pg_dump.

So, keywords.c would look like:

#include "parser/keywords.h"
const ScanKeyword ScanKeywords[] = {
/* name, value, category */
PG_KEYWORD("abort", ABORT_P, UNRESERVED_KEYWORD),
PG_KEYWORD("absolute", ABSOLUTE_P, UNRESERVED_KEYWORD),
PG_KEYWORD("access", ACCESS, UNRESERVED_KEYWORD),
...

And there would be a new file in src/bin/pg_dump, say dumpkeywords.c,
that looks like this:

#include "c.h"

#define PG_KEYWORD(a,b,c) {a,b,c}
#include "src/backend/parser/keywords.c"

Not sure what to do about ScanKeywordLookup function.

> /*
> + * We don't want to include the gram.h file on frontend builds, except ECPG, so
> + * leave out the second struct member in that case.
> + */
> + #if !defined FRONTEND || defined ECPG_COMPILE
> + #define PG_KEYWORD(a,b,c) {a,b,c}
> + #else
> + #define PG_KEYWORD(a,b,c) {a,c}
> + #endif

Doesn't that put 'c' into the wrong field in ScanKeyword struct? It only
compiles because both 'value' and 'category' are int16.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com