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 [extensi
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
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
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 tight
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 com
