Dne 3.03.09 22:55, Tom Lane napsal(a):
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
Zdenek Kotala wrote:
Dne 3.03.09 22:55, Tom Lane napsal(a):
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
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Seems doable.
Attached.
The TWO_MEMBER_SCANKEYWORD business seems a bit dangerous --- if the
header file is read without having #defined that correctly, bad things
will happen. It might be better to leave that out,
On Thu, Mar 5, 2009 at 1:12 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Seems doable.
Attached.
The TWO_MEMBER_SCANKEYWORD business seems a bit dangerous --- if the
header file is read without having #defined that
Alvaro Herrera alvhe...@commandprompt.com writes:
Hopefully this is the last version of this patch.
A few more comments would help --- in particular the header comment
for kwlist.h should explain that the calling file is supposed to define
PG_KEYWORD appropriately for its needs. I also wonder
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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
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.
What I'd suggest is something similar to the design of
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
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
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.
What I'd suggest is something
Heikki Linnakangas wrote:
Alvaro Herrera wrote:
/*
+ * 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
Alvaro Herrera wrote:
Tom Lane wrote:
What I'd suggest is something similar to the design of the errcodes.h
header: create a header file containing just the list of PG_KEYWORD
macro calls, and have the different users #include it after defining
that macro appropriately. Having .c files
Alvaro Herrera wrote:
Alvaro Herrera wrote:
Tom Lane wrote:
What I'd suggest is something similar to the design of the errcodes.h
header: create a header file containing just the list of PG_KEYWORD
macro calls, and have the different users #include it after defining
that macro
Alvaro Herrera alvhe...@commandprompt.com writes:
Seems doable.
Attached.
The TWO_MEMBER_SCANKEYWORD business seems a bit dangerous --- if the
header file is read without having #defined that correctly, bad things
will happen. It might be better to leave that out, always define the
struct the
Hi,
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:
make -C ../../../src/backend/parser keywords.o
make[1]: Entering directory
`/home/alvherre/Code/CVS/pgsql/build/00head/src/backend/parser'
gcc -O0 -Wall
Alvaro Herrera wrote:
Hi,
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:
make -C ../../../src/backend/parser keywords.o
make[1]: Entering directory
`/home/alvherre/Code/CVS/pgsql/build/00head/src/backend/parser'
Alvaro Herrera alvhe...@commandprompt.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
Tom Lane wrote:
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
17 matches
Mail list logo
