Re: [PATCHES] Fix pg_dump dependency on postgres.h
Tom Lane napsal(a): Zdenek Kotala [EMAIL PROTECTED] writes: Thank your for Your and Alvaro's comments. I attached updated patch version only with YYSTYPE definition. Applied with minor revisions. I fixed pg_conversion.h as well; the only remaining special inclusions in the catalog header files are of pg_list.h. For the moment that header doesn't seem to be a problem for client-side code to include, but someday we may want to do more cleanup here. Thanks. The immediate remaining problem is that pg_resetxlog.c still includes a bunch of backend-only headers, which as far as I understand still blocks your build requirements. I poked at this a little bit, but didn't see any easy solution ... Yes, I know about it. When I tried to solved it in November, I found some unnecessary includes and also there are some not well placed structures and so on. I also sent one fix which probably lost in black hole of patch queue: See http://archives.postgresql.org/pgsql-patches/2007-10/msg00197.php There are big work on pg_resetxlog.c and I will look on it. It probably will require a cleanup in headers files. Zdenek -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Fix pg_dump dependency on postgres.h
Zdenek Kotala [EMAIL PROTECTED] writes: Thank your for Your and Alvaro's comments. I attached updated patch version only with YYSTYPE definition. Applied with minor revisions. I fixed pg_conversion.h as well; the only remaining special inclusions in the catalog header files are of pg_list.h. For the moment that header doesn't seem to be a problem for client-side code to include, but someday we may want to do more cleanup here. The immediate remaining problem is that pg_resetxlog.c still includes a bunch of backend-only headers, which as far as I understand still blocks your build requirements. I poked at this a little bit, but didn't see any easy solution ... regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Fix pg_dump dependency on postgres.h
Tom Lane napsal(a):
(a) it wasn't to build at all, it was to allow inline to be enabled
on Sun Studio's compiler, which apparently is too dumb to not generate
copies of an unreferenced inline function.
I don't think that you have right. inline is just optimizer hint and Sun Studio
performs inline optimization from level 3 (-xO3). In lower level it generates
it as local function. And on other side GCC (3.4.3) performs inconsistent
optimization on -O0 level which is by my opinion also for discussion see
following case:
-
#include stdio.h
static inline int test_1(int a)
{
return a*a;
}
static inline int test_2(int p)
{
return p*p;
}
static int test_3(int p)
{
return p*p;
}
int main()
{
int a = 3;
printf(%i\n, test_1(a));
return 0;
}
bash-3.2$ nm ./a.out | grep test
[58]| 134548680|15|FUNC |LOCL |0|13 |test_1
[57]| 134548592|15|FUNC |LOCL |0|13 |test_3
-
Why test_3 is not removed as unused function, but test_2 is? By my opinion it is
inconsistent. GCC removes test_3 on -O2 level. And why -fkeep-inline-functions
does not work? It seems to me that somebody modify gcc to fix similar problems
as postgreSQL has in the source code.
Zdenek
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [PATCHES] Fix pg_dump dependency on postgres.h
Bruce Momjian wrote: Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Huh, I think the point is to be able to build 8.3 at all on certain Solaris releases. I think it qualifies as a portability fix. (a) it wasn't to build at all, it was to allow inline to be enabled on Sun Studio's compiler, which apparently is too dumb to not generate copies of an unreferenced inline function. (b) portability fix or not, this ain't going into 8.3. It's *far* too invasive for this late stage of the cycle. Yea, that was my analysis too. Oh, right, I misremembered that it was only to allow inline. -- Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J En las profundidades de nuestro inconsciente hay una obsesiva necesidad de un universo lógico y coherente. Pero el universo real se halla siempre un paso más allá de la lógica (Irulan) ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] Fix pg_dump dependency on postgres.h
Bruce Momjian wrote: Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Huh, I think the point is to be able to build 8.3 at all on certain Solaris releases. I think it qualifies as a portability fix. (a) it wasn't to build at all, it was to allow inline to be enabled on Sun Studio's compiler, which apparently is too dumb to not generate copies of an unreferenced inline function. (b) portability fix or not, this ain't going into 8.3. It's *far* too invasive for this late stage of the cycle. Yea, that was my analysis too. Yes, I agree with Bruce and Tom. It is more invasive then I expected. And specially in context when pg_resetxlog needs to be also fixed and this fix seems more complicated then pg_dump fix :(. Zdenek ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Fix pg_dump dependency on postgres.h
Zdenek Kotala wrote: Bruce Momjian wrote: Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Huh, I think the point is to be able to build 8.3 at all on certain Solaris releases. I think it qualifies as a portability fix. (a) it wasn't to build at all, it was to allow inline to be enabled on Sun Studio's compiler, which apparently is too dumb to not generate copies of an unreferenced inline function. (b) portability fix or not, this ain't going into 8.3. It's *far* too invasive for this late stage of the cycle. Yea, that was my analysis too. Yes, I agree with Bruce and Tom. It is more invasive then I expected. And specially in context when pg_resetxlog needs to be also fixed and this fix seems more complicated then pg_dump fix :(. The good news is that we will have it ready for 8.4. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Fix pg_dump dependency on postgres.h
This has been saved for the 8.4 release: http://momjian.postgresql.org/cgi-bin/pgpatches_hold --- Zdenek Kotala wrote: Tom Lane wrote: snip AFAICT, therefore, the proposed patch should only define YYSTYPE and not anything else (there's no need to be afraid of YYLTYPE at present). Thank your for Your and Alvaro's comments. I attached updated patch version only with YYSTYPE definition. Thanks Zdenek ---(end of broadcast)--- TIP 6: explain analyze is your friend -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] Fix pg_dump dependency on postgres.h
Bruce Momjian wrote: This has been saved for the 8.4 release: http://momjian.postgresql.org/cgi-bin/pgpatches_hold Huh, I think the point is to be able to build 8.3 at all on certain Solaris releases. I think it qualifies as a portability fix. --- Zdenek Kotala wrote: Tom Lane wrote: snip AFAICT, therefore, the proposed patch should only define YYSTYPE and not anything else (there's no need to be afraid of YYLTYPE at present). Thank your for Your and Alvaro's comments. I attached updated patch version only with YYSTYPE definition. -- Alvaro Herrera Valdivia, Chile ICBM: S 39º 49' 18.1, W 73º 13' 56.4 No es bueno caminar con un hombre muerto ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Fix pg_dump dependency on postgres.h
Alvaro Herrera wrote: Bruce Momjian wrote: This has been saved for the 8.4 release: http://momjian.postgresql.org/cgi-bin/pgpatches_hold Huh, I think the point is to be able to build 8.3 at all on certain Solaris releases. I think it qualifies as a portability fix. I thought this was just cleanup. Why does Solaris need it? I don't remember it has been so long. I see it referenced here: http://archives.postgresql.org/pgsql-hackers/2007-10/msg01261.php Is this some Sun bug or an optimization that is causing the problem. The fact that this patch is not in beta3 has me worried about putting it in with no beta before RC1. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Fix pg_dump dependency on postgres.h
Alvaro Herrera [EMAIL PROTECTED] writes: Huh, I think the point is to be able to build 8.3 at all on certain Solaris releases. I think it qualifies as a portability fix. (a) it wasn't to build at all, it was to allow inline to be enabled on Sun Studio's compiler, which apparently is too dumb to not generate copies of an unreferenced inline function. (b) portability fix or not, this ain't going into 8.3. It's *far* too invasive for this late stage of the cycle. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Fix pg_dump dependency on postgres.h
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Huh, I think the point is to be able to build 8.3 at all on certain Solaris releases. I think it qualifies as a portability fix. (a) it wasn't to build at all, it was to allow inline to be enabled on Sun Studio's compiler, which apparently is too dumb to not generate copies of an unreferenced inline function. (b) portability fix or not, this ain't going into 8.3. It's *far* too invasive for this late stage of the cycle. Yea, that was my analysis too. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] Fix pg_dump dependency on postgres.h
Zdenek Kotala wrote: Zdenek Kotala wrote: Zdenek Kotala wrote: Attached patch removes pg_dump dependency on postgres.h. The main reason for that was discussed there: http://archives.postgresql.org/pgsql-hackers/2007-10/msg01261.php I found two problems there. One is that I forgot postgres.h include in common.c. it is easy to fix. However second problem is more complicated. dumputils.c calls ScandKeywordLookup function which is defined in keyword.c. :( snip 3) Put following fake into keyword.c before include parse.h line. It is easiest way. #define TYPE_IS_DECLARED 1 #define YYLTYPE_IS_DECLARED 1 #define YYLTYPE void* #define YYSTYPE void* New version of patch is attached. I selected variant 3 as a best solution. Patch also fix some other postgres.h dependencyin another tools such as pg_controldata, pg_config. The last unfixed tool is pg_resetxlog which deserves own patch. Humm, but YYLTYPE is defined in gramparse.h (and as a different type) ... Also, I see that if you define YYLTYPE then you don't need YYLTYPE_IS_DECLARED as well. Also I don't see any TYPE_IS_DECLARED here. What I'm thinking is that this patch is not very portable :-( -- Alvaro Herrera Valdivia, Chile ICBM: S 39º 49' 18.1, W 73º 13' 56.4 Llegará una época en la que una investigación diligente y prolongada sacará a la luz cosas que hoy están ocultas (Séneca, siglo I) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Fix pg_dump dependency on postgres.h
Alvaro Herrera wrote: Zdenek Kotala wrote: Zdenek Kotala wrote: Zdenek Kotala wrote: Attached patch removes pg_dump dependency on postgres.h. The main reason for that was discussed there: http://archives.postgresql.org/pgsql-hackers/2007-10/msg01261.php I found two problems there. One is that I forgot postgres.h include in common.c. it is easy to fix. However second problem is more complicated. dumputils.c calls ScandKeywordLookup function which is defined in keyword.c. :( snip 3) Put following fake into keyword.c before include parse.h line. It is easiest way. #define TYPE_IS_DECLARED 1 #define YYLTYPE_IS_DECLARED 1 #define YYLTYPE void* #define YYSTYPE void* New version of patch is attached. I selected variant 3 as a best solution. Patch also fix some other postgres.h dependencyin another tools such as pg_controldata, pg_config. The last unfixed tool is pg_resetxlog which deserves own patch. Humm, but YYLTYPE is defined in gramparse.h (and as a different type) ... Also, I see that if you define YYLTYPE then you don't need YYLTYPE_IS_DECLARED as well. Also I don't see any TYPE_IS_DECLARED here. What I'm thinking is that this patch is not very portable :-( Thanks you for your comments. You are right, define YYLTYPE and YYSTYPE is enough to skip union/structure definition. I think, data type is not important for this purpose, but use int instead of void* seem good idea. It will be synchronized with gramparse.h. What do you mean not very portable? What could be problem there? Zdenek ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] Fix pg_dump dependency on postgres.h
Zdenek Kotala wrote: Alvaro Herrera wrote: 3) Put following fake into keyword.c before include parse.h line. It is easiest way. #define TYPE_IS_DECLARED 1 #define YYLTYPE_IS_DECLARED 1 #define YYLTYPE void* #define YYSTYPE void* New version of patch is attached. I selected variant 3 as a best solution. Patch also fix some other postgres.h dependencyin another tools such as pg_controldata, pg_config. The last unfixed tool is pg_resetxlog which deserves own patch. Humm, but YYLTYPE is defined in gramparse.h (and as a different type) ... Also, I see that if you define YYLTYPE then you don't need YYLTYPE_IS_DECLARED as well. Also I don't see any TYPE_IS_DECLARED here. What I'm thinking is that this patch is not very portable :-( Thanks you for your comments. You are right, define YYLTYPE and YYSTYPE is enough to skip union/structure definition. I think, data type is not important for this purpose, but use int instead of void* seem good idea. It will be synchronized with gramparse.h. What do you mean not very portable? What could be problem there? I'm not sure. My point is that it seems your parse.h requires TYPE_IS_DECLARED, but mine doesn't. What else could be lurking in there that requires a specific fix? In order to avoid that, it would be better if there was a solution to the problem along the lines of #2 you proposed. -- Alvaro Herrera Developer, http://www.PostgreSQL.org/ No renuncies a nada. No te aferres a nada. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Fix pg_dump dependency on postgres.h
Alvaro Herrera wrote: Zdenek Kotala wrote: Alvaro Herrera wrote: 3) Put following fake into keyword.c before include parse.h line. It is easiest way. #define TYPE_IS_DECLARED 1 #define YYLTYPE_IS_DECLARED 1 #define YYLTYPE void* #define YYSTYPE void* New version of patch is attached. I selected variant 3 as a best solution. Patch also fix some other postgres.h dependencyin another tools such as pg_controldata, pg_config. The last unfixed tool is pg_resetxlog which deserves own patch. Humm, but YYLTYPE is defined in gramparse.h (and as a different type) ... Also, I see that if you define YYLTYPE then you don't need YYLTYPE_IS_DECLARED as well. Also I don't see any TYPE_IS_DECLARED here. What I'm thinking is that this patch is not very portable :-( Thanks you for your comments. You are right, define YYLTYPE and YYSTYPE is enough to skip union/structure definition. I think, data type is not important for this purpose, but use int instead of void* seem good idea. It will be synchronized with gramparse.h. What do you mean not very portable? What could be problem there? I'm not sure. My point is that it seems your parse.h requires TYPE_IS_DECLARED, but mine doesn't. What else could be lurking in there that requires a specific fix? In order to avoid that, it would be better if there was a solution to the problem along the lines of #2 you proposed. TYPE_IS_DECLARED was my mistake. It should be YYSTYPE_IS_DECLARED. It works because YYSTYPE is also defined and #ifdef checks both. Copy and paste :( error. Sorry for confusion. I'm going to send new version. Zdenek ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] Fix pg_dump dependency on postgres.h
Alvaro Herrera [EMAIL PROTECTED] writes: Zdenek Kotala wrote: What do you mean not very portable? What could be problem there? I'm not sure. My point is that it seems your parse.h requires TYPE_IS_DECLARED, but mine doesn't. What else could be lurking in there that requires a specific fix? The portability axis of concern here is portability across different versions of bison. ATM I believe we work with everything from 1.875 up, and I'd be loath to give that up. I concur with Alvaro that this feels like a kluge rather than a permanent solution. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] Fix pg_dump dependency on postgres.h
Zdenek Kotala [EMAIL PROTECTED] writes: TYPE_IS_DECLARED was my mistake. It should be YYSTYPE_IS_DECLARED. It works because YYSTYPE is also defined and #ifdef checks both. Copy and paste :( error. Sorry for confusion. I'm going to send new version. [ after further review... ] It looks to me like the intended use of YYSTYPE_IS_DECLARED is to denote the case where the user has supplied a typedef, not macro, definition of YYSTYPE. So defining YYSTYPE as a macro and setting YYSTYPE_IS_DECLARED as well really seems incorrect. The real question with all this is that while the Bison manual clearly says that you can #define YYSTYPE, there is not anything suggesting that you can or should do that when using %union; they are presented as two different ways of defining the type. So I find it a bit surprising that the #if is there at all in parse.h. Nonetheless it is there in all versions from 1.875 to 2.3, and in the 2.3 manual it says Unless `YYSTYPE' is already defined as a macro, the output header declares `YYSTYPE'. So apparently the Bison guys do intend to carry that behavior forward. AFAICT, therefore, the proposed patch should only define YYSTYPE and not anything else (there's no need to be afraid of YYLTYPE at present). regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Fix pg_dump dependency on postgres.h
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Zdenek Kotala wrote: What do you mean not very portable? What could be problem there? I'm not sure. My point is that it seems your parse.h requires TYPE_IS_DECLARED, but mine doesn't. What else could be lurking in there that requires a specific fix? The portability axis of concern here is portability across different versions of bison. ATM I believe we work with everything from 1.875 up, and I'd be loath to give that up. I concur with Alvaro that this feels like a kluge rather than a permanent solution. But, if you look into gramparse.h it also redefine YYLTYPE for own purpose. It is similar mechanism. However YYSTYPE definition generates different storage for base_yylval. It could be problem with some compiler/linker. :( Unfortunately, I don't see any solution with modification gram.y (I'm not bison hunter). Another solution is what ecpg does. It has own modified copy of keyword.c. But it will require to keep it synchronized. Or if we put parentheses around all columns we don't need keyword.c. It also fix a problem with old dump file when we introduce new keyword in the future. Zdenek ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Fix pg_dump dependency on postgres.h
Zdenek Kotala wrote: Attached patch removes pg_dump dependency on postgres.h. The main reason for that was discussed there: http://archives.postgresql.org/pgsql-hackers/2007-10/msg01261.php I found two problems there. One is that I forgot postgres.h include in common.c. it is easy to fix. However second problem is more complicated. dumputils.c calls ScandKeywordLookup function which is defined in keyword.c. :( I currently see two possible variant: 1) Put list of RESERVED keyword into dumputils and use bsearch for lookup. It is easy to implement but it will be difficult to keep synchronize these two list together. 2) Modify gram.y to generate parse.h which will be friendly for backend and can be used in keyword.c. Probably add some ifdef ... 3) Put following fake into keyword.c before include parse.h line. It is easiest way. #define TYPE_IS_DECLARED 1 #define YYLTYPE_IS_DECLARED 1 #define YYLTYPE void* #define YYSTYPE void* Comments or any ideas? Zdenek ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[PATCHES] Fix pg_dump dependency on postgres.h
Attached patch removes pg_dump dependency on postgres.h. The main reason for that was discussed there: http://archives.postgresql.org/pgsql-hackers/2007-10/msg01261.php This fix contains several steps: 1) I removed sugar word from postgres.h and put them closer to consumer :-). I created include/catalog/genbki.h which contains sugar words - macros for correct catalog data processing. All catalogs file now include this header. 2) I moved SEQ_MAXVALUE and SEQ_MINVALUE macros from sequence.h to postgres_config_manual.h 3) I created two new headers pg_type_fn.h and pg_proc_fn.h and I moved all extern function definition from related headers into them. Second possible solution could be let function definition into headers and fence them by #ifndef FRONTED. Let me know your comments. Thanks Zdenek pg_dump.patch.gz Description: GNU Zip compressed data ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Fix pg_dump dependency on postgres.h
Zdenek Kotala wrote: Attached patch removes pg_dump dependency on postgres.h. The main reason for that was discussed there: http://archives.postgresql.org/pgsql-hackers/2007-10/msg01261.php This fix contains several steps: 1) I removed sugar word from postgres.h and put them closer to consumer :-). I created include/catalog/genbki.h which contains sugar words - macros for correct catalog data processing. All catalogs file now include this header. What's the point of this? I don't see what difference it makes from the current situation. In particular I don't see it being included in any new place. The other two changes seem to be what was discussed: 2) I moved SEQ_MAXVALUE and SEQ_MINVALUE macros from sequence.h to postgres_config_manual.h 3) I created two new headers pg_type_fn.h and pg_proc_fn.h and I moved all extern function definition from related headers into them. -- Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC One man's impedance mismatch is another man's layer of abstraction. (Lincoln Yeoh) ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Fix pg_dump dependency on postgres.h
Alvaro Herrera wrote: Zdenek Kotala wrote: Attached patch removes pg_dump dependency on postgres.h. The main reason for that was discussed there: http://archives.postgresql.org/pgsql-hackers/2007-10/msg01261.php This fix contains several steps: 1) I removed sugar word from postgres.h and put them closer to consumer :-). I created include/catalog/genbki.h which contains sugar words - macros for correct catalog data processing. All catalogs file now include this header. What's the point of this? I don't see what difference it makes from the current situation. In particular I don't see it being included in any new place. The problem is that postgres.h include palloc.h which contains extern declaration of MemoryContext global variable. It is not correct for tools as pg_dump is. Because it does not use palloc. When I enabled inline functions and start compiling postgres with sunstudio, linking phase failed on pg_dump because MemoryContext is not allocated. It is background of problem. pg_dump.c needs some macros which are defined into catalogs header. But it should not include postgres.h where is defined sugar words for catalog data. It is the reason why I moved these macros to the separate header and include this header from all catalog header. It was discussed there: http://archives.postgresql.org/pgsql-hackers/2007-10/msg01277.php Zdenek ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Fix pg_dump dependency on postgres.h
Zdenek Kotala wrote: Alvaro Herrera wrote: 1) I removed sugar word from postgres.h and put them closer to consumer :-). I created include/catalog/genbki.h which contains sugar words - macros for correct catalog data processing. All catalogs file now include this header. What's the point of this? I don't see what difference it makes from the current situation. In particular I don't see it being included in any new place. pg_dump.c needs some macros which are defined into catalogs header. But it should not include postgres.h where is defined sugar words for catalog data. It is the reason why I moved these macros to the separate header and include this header from all catalog header. Ah, the part that I was missing was that the catalog headers were being included by pg_dump.c. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
