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
Greets,
Would it be possible to get something along the lines of the attached
patch in 8? (major,minor,patch,state version defines)
(I tried making them shell vars and giving it to AC_INIT, but it seemed
to want a literal, so...)
Yes, I know there are other ways to get and define this informatio
