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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
