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