Re: [HACKERS] Version defines
James William Pye [EMAIL PROTECTED] writes: Would it be possible to get something along the lines of the attached patch in 8? (major,minor,patch,state version defines) This has been proposed and rejected before, mainly on the grounds that it would encourage bad programming practices. At compile time, you should be checking the specific feature you care about, not a system version number (this is pretty much the entire point behind Autoconf). At run time, you need to be making a run-time test anyway; compiling against version x.y headers does not guarantee anything about what version you will be executing against at runtime. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Version defines
On Sun, 2004-10-31 at 08:02, Tom Lane wrote: This has been proposed and rejected before, mainly on the grounds that it would encourage bad programming practices. I admit that I am probably practicing this bad programming at few places in my source, and shame on me for it. I have hoped to tighten it up a bit later, but it is convenient for the time being. At compile time, you should be checking the specific feature you care about, Well, for one of my uses, it is not a feature check. My PL loads a Python extension module whose path is dependent on the major and minor version of the PostgreSQL installation that the PL was compiled against. So I construct the module path string based on the major and minor at compile time. If this is the stance that the group has, that is fine. For now, I will continue my shameful practice of parsing up pg_config --version and defining the components for use in my source. (; -- Regards, James William Pye signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Version defines
James William Pye [EMAIL PROTECTED] writes: At compile time, you should be checking the specific feature you care about, Well, for one of my uses, it is not a feature check. My PL loads a Python extension module whose path is dependent on the major and minor version of the PostgreSQL installation that the PL was compiled against. So I construct the module path string based on the major and minor at compile time. Er ... can't you just keep it in pkglibdir and refer to it via $libdir? Given that 8.0 now supports relocatable installations, I'd think it best to avoid hardwiring any paths at compile time. regards, tom lane ---(end of broadcast)--- TIP 3: 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: [HACKERS] Version defines
James William Pye wrote: If this is the stance that the group has, that is fine. For now, I will continue my shameful practice of parsing up pg_config --version and defining the components for use in my source. (; FWIW, here's what I've been using in PL/R for a while now: /* working with postgres 7.3 compatible sources */ #if (CATALOG_VERSION_NO = 200211021) #define PG_VERSION_73_COMPAT #elif (CATALOG_VERSION_NO = 200310211) #define PG_VERSION_74_COMPAT #else #define PG_VERSION_75_COMPAT #endif Joe ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Version defines
On Sun, 2004-10-31 at 10:49, Tom Lane wrote: Er ... can't you just keep it in pkglibdir and refer to it via $libdir? Given that 8.0 now supports relocatable installations, I'd think it best to avoid hardwiring any paths at compile time. Hmm.. I think it would be best to keep Python [extension] modules in Python's site-packages. AFA hardwiring is concerned, I will probably make it a GUC variable in 8.0 that will default to how I currently hardwire it. -- Regards, James William Pye signature.asc Description: This is a digitally signed message part
