Re: [HACKERS] datetime.h defines like PM conflict with external libraries
> Isn't pgtypeslib/*.h exposed to ecpg-using applications? No, the public interface is is include/*.h, pgtypeslib/*.h is only internal. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] datetime.h defines like PM conflict with external libraries
Michael Meskes writes: >> Maybe it'd be good idea to unify some of that stuff so that ecpg can >> use it, too? Having a second copy of the same stuff in >> src/interfaces/ecpg/pgtypeslib/dt.h is pretty terrible. Even if not, >> let's make sure they don't diverge. > Please let's unify whatever we can. The fewer manual sync we need, the > better. Isn't pgtypeslib/*.h exposed to ecpg-using applications? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] datetime.h defines like PM conflict with external libraries
> Maybe it'd be good idea to unify some of that stuff so that ecpg can > use > it, too? Having a second copy of the same stuff in > src/interfaces/ecpg/pgtypeslib/dt.h is pretty terrible. Even if not, > let's make sure they don't diverge. Please let's unify whatever we can. The fewer manual sync we need, the better. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] datetime.h defines like PM conflict with external libraries
Andrew Dunstan wrote: > On 10/03/2017 04:43 PM, Tom Lane wrote: > > I like the new-header-file idea because it will result in minimal code > > churn and thus minimal back-patching hazards. > > > > I do *not* like "PG_PM". For our own purposes that adds no uniqueness > > at all. If we're to touch these symbols then I'd go for names like > > "DATETIME_PM". Or maybe "DT_PM" ... there's a little bit of precedent > > for the DT_ prefix already. > > Yeah. If we use a prefix +1 for DT_. If we do that then I think they > should *all* be prefixed, not just the ones we know of conflicts for. Maybe it'd be good idea to unify some of that stuff so that ecpg can use it, too? Having a second copy of the same stuff in src/interfaces/ecpg/pgtypeslib/dt.h is pretty terrible. Even if not, let's make sure they don't diverge. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] datetime.h defines like PM conflict with external libraries
On 10/03/2017 04:43 PM, Tom Lane wrote: > Andres Freund writes: >> On 2017-10-03 16:34:38 -0400, Andrew Dunstan wrote: >>> AFAICT at a quick glance these are only used in a couple of files. Maybe >>> the defs need to be floated off to a different header with more limited >>> inclusion? >> Why not just rename them to PG_PM etc? If we force potential external >> users to do some changes, we can use more unique names just as well - >> the effort to adapt won't be meaningfully higher... IMNSHO there's not >> much excuse for defining macros like PM globally. > I like the new-header-file idea because it will result in minimal code > churn and thus minimal back-patching hazards. > > I do *not* like "PG_PM". For our own purposes that adds no uniqueness > at all. If we're to touch these symbols then I'd go for names like > "DATETIME_PM". Or maybe "DT_PM" ... there's a little bit of precedent > for the DT_ prefix already. > > Yeah. If we use a prefix +1 for DT_. If we do that then I think they should *all* be prefixed, not just the ones we know of conflicts for. cheers andrew -- Andrew Dunstanhttps://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] datetime.h defines like PM conflict with external libraries
Andres Freund writes: > On 2017-10-03 16:34:38 -0400, Andrew Dunstan wrote: >> AFAICT at a quick glance these are only used in a couple of files. Maybe >> the defs need to be floated off to a different header with more limited >> inclusion? > Why not just rename them to PG_PM etc? If we force potential external > users to do some changes, we can use more unique names just as well - > the effort to adapt won't be meaningfully higher... IMNSHO there's not > much excuse for defining macros like PM globally. I like the new-header-file idea because it will result in minimal code churn and thus minimal back-patching hazards. I do *not* like "PG_PM". For our own purposes that adds no uniqueness at all. If we're to touch these symbols then I'd go for names like "DATETIME_PM". Or maybe "DT_PM" ... there's a little bit of precedent for the DT_ prefix already. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] datetime.h defines like PM conflict with external libraries
Hi, On 2017-10-03 16:34:38 -0400, Andrew Dunstan wrote: > On 10/03/2017 03:00 PM, Andres Freund wrote: > > Hi, > > > > In my llvm jit work I'd to > > > > #undef PM > > /* include some llvm headers */ > > #define PM 1 > > > > because llvm has a number of functions which have an argument named PM. > > Now that works, but it's fairly ugly. Perhaps it would be a good idea to > > name these defines in a manner that's slightly less likely to conflict? > > > > Alternatively we could use #pragma push_macro() around the includes, but > > that'd be a new dependency. > > > > Better ideas? > AFAICT at a quick glance these are only used in a couple of files. Maybe > the defs need to be floated off to a different header with more limited > inclusion? Why not just rename them to PG_PM etc? If we force potential external users to do some changes, we can use more unique names just as well - the effort to adapt won't be meaningfully higher... IMNSHO there's not much excuse for defining macros like PM globally. - Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] datetime.h defines like PM conflict with external libraries
On 10/03/2017 03:00 PM, Andres Freund wrote: > Hi, > > In my llvm jit work I'd to > > #undef PM > /* include some llvm headers */ > #define PM 1 > > because llvm has a number of functions which have an argument named PM. > Now that works, but it's fairly ugly. Perhaps it would be a good idea to > name these defines in a manner that's slightly less likely to conflict? > > Alternatively we could use #pragma push_macro() around the includes, but > that'd be a new dependency. > > Better ideas? > AFAICT at a quick glance these are only used in a couple of files. Maybe the defs need to be floated off to a different header with more limited inclusion? cheers andrew -- Andrew Dunstanhttps://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] datetime.h defines like PM conflict with external libraries
Hi, In my llvm jit work I'd to #undef PM /* include some llvm headers */ #define PM 1 because llvm has a number of functions which have an argument named PM. Now that works, but it's fairly ugly. Perhaps it would be a good idea to name these defines in a manner that's slightly less likely to conflict? Alternatively we could use #pragma push_macro() around the includes, but that'd be a new dependency. Better ideas? Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers