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
