pg.ddx.io  pgsql-interfaces@postgresql.org mailing list archive  
help / color / mirror / Atom feed
Finding the pqlib version
33+ messages / 7 participants
[nested] [flat]

* Finding the pqlib version
@ 2006-02-11 10:59  Christoph Zwerschke <cito@online.de>
  0 siblings, 3 replies; 33+ messages in thread

From: Christoph Zwerschke @ 2006-02-11 10:59 UTC (permalink / raw)
  To: pgsql-interfaces

I want to add the PQCancel() functionality to PyGreSQL.
Until now, PyGreSQL works with PostgreSQL 7.3+, but
unfortunately, PQCancel() is only available from 8.0+.

In order to not break compilation of PyGreSQL on systems with PG7,
I would like to do something like the following:

#if PQLIB_VERSION_MAJOR < 8
   PQRequestCancel(conn)
#else
   c = PQgetCancel(conn)
   PQCancel(c, errbuf, 256)
   PQfreeCancel(c)
#end

However, there is no such thing as "PQLIB_VERSION_MAJOR".
Anything else I could query instead?

-- Christoph




^ permalink  raw  reply  [nested|flat] 33+ messages in thread

* Re: Finding the pqlib version
@ 2006-02-11 12:57  Greg Sabino Mullane <greg@turnstep.com>
  parent: Christoph Zwerschke <cito@online.de>
  2 siblings, 0 replies; 33+ messages in thread

From: Greg Sabino Mullane @ 2006-02-11 12:57 UTC (permalink / raw)
  To: pgsql-interfaces


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

  
> However, there is no such thing as "PQLIB_VERSION_MAJOR".
> Anything else I could query instead?

Call "pg_config --version" and break it into pieces. To make life
easier, meld them back together into a single string with something
like this:

my $serverversion = sprintf("%d%.02d%.02d", $major_ver, $minor_ver, $patch);

Then you can do things like
if ($serverversion >= 80000) ...

and can similarly pass the above to cc via a -D and get some ifdef fun...

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200602110755
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8

-----BEGIN PGP SIGNATURE-----

iD8DBQFD7d8FvJuQZxSWSsgRAhuMAJ4sShLpZWOUUSFVbBqfnS4UB2GuTwCgnpgl
d3HjVGFhiS5H5xNf/M2qllU=
=z7X9
-----END PGP SIGNATURE-----





^ permalink  raw  reply  [nested|flat] 33+ messages in thread

* Re: Finding the pqlib version
@ 2006-02-11 13:50  Peter Eisentraut <peter_e@gmx.net>
  parent: Christoph Zwerschke <cito@online.de>
  2 siblings, 2 replies; 33+ messages in thread

From: Peter Eisentraut @ 2006-02-11 13:50 UTC (permalink / raw)
  To: pgsql-interfaces; +Cc: Christoph Zwerschke <cito@online.de>

Christoph Zwerschke wrote:
> However, there is no such thing as "PQLIB_VERSION_MAJOR".
> Anything else I could query instead?

You should query the presence of the function, not the version of the 
library.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/



^ permalink  raw  reply  [nested|flat] 33+ messages in thread

* Re: Finding the pqlib version
@ 2006-02-11 15:01  Bruce Momjian <pgman@candle.pha.pa.us>
  parent: Christoph Zwerschke <cito@online.de>
  2 siblings, 1 reply; 33+ messages in thread

From: Bruce Momjian @ 2006-02-11 15:01 UTC (permalink / raw)
  To: Christoph Zwerschke <cito@online.de>; +Cc: pgsql-interfaces

Christoph Zwerschke wrote:
> I want to add the PQCancel() functionality to PyGreSQL.
> Until now, PyGreSQL works with PostgreSQL 7.3+, but
> unfortunately, PQCancel() is only available from 8.0+.
> 
> In order to not break compilation of PyGreSQL on systems with PG7,
> I would like to do something like the following:
> 
> #if PQLIB_VERSION_MAJOR < 8
>    PQRequestCancel(conn)
> #else
>    c = PQgetCancel(conn)
>    PQCancel(c, errbuf, 256)
>    PQfreeCancel(c)
> #end
> 
> However, there is no such thing as "PQLIB_VERSION_MAJOR".
> Anything else I could query instead?

You want the server version.  In PostgreSQL 8.0 and later you can use
libpq's PQserverVersion(), but for pre-8.0, I think you have to do
SELECT version(), and parse that:

	test=> SELECT version();
	                             version
	------------------------------------------------------------------
	 PostgreSQL 8.2devel on i386-pc-bsdi4.3.1, compiled by GCC 2.95.3
	(1 row)

I would also look how other interfaces are doing this.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073



^ permalink  raw  reply  [nested|flat] 33+ messages in thread

* Re: Finding the pqlib version
@ 2006-02-11 15:44  Christoph Zwerschke <cito@online.de>
  parent: Peter Eisentraut <peter_e@gmx.net>
  1 sibling, 3 replies; 33+ messages in thread

From: Christoph Zwerschke @ 2006-02-11 15:44 UTC (permalink / raw)
  To: pgsql-interfaces

Peter Eisentraut wrote:
> You should query the presence of the function, not the version of the 
> library.

Yes, but it will complicate things. I will probably have to use 
something like "configure" to do this. So far, this hasn't been 
necessary. So I'd prefer a simple hack. Or how would you to this?

-- Christoph



^ permalink  raw  reply  [nested|flat] 33+ messages in thread

* Re: Finding the pqlib version
@ 2006-02-11 16:03  Christoph Zwerschke <cito@online.de>
  parent: Bruce Momjian <pgman@candle.pha.pa.us>
  0 siblings, 0 replies; 33+ messages in thread

From: Christoph Zwerschke @ 2006-02-11 16:03 UTC (permalink / raw)
  To: pgsql-interfaces

Bruce Momjian wrote:
> You want the server version.  In PostgreSQL 8.0 and later you can use
> libpq's PQserverVersion(), but for pre-8.0, I think you have to do
> SELECT version(), and parse that:

I'd prefer something defined in the Postgres include files that can be 
checked by the precompiler already. In Python, the version information 
with major, minor and micro is defined in patchlevel.h and can be used 
for conditional compilation. It would be nice if something like this 
existed also for Postgres. I noticed pg_config.h has PG_VERSION, but it 
is the compound version of major, minor and micro including the dots 
which cannot be easily compared.

-- Christoph



^ permalink  raw  reply  [nested|flat] 33+ messages in thread

* Re: Finding the pqlib version
@ 2006-02-11 17:39  Tom Lane <tgl@sss.pgh.pa.us>
  parent: Christoph Zwerschke <cito@online.de>
  2 siblings, 0 replies; 33+ messages in thread

From: Tom Lane @ 2006-02-11 17:39 UTC (permalink / raw)
  To: Christoph Zwerschke <cito@online.de>; +Cc: pgsql-interfaces

Christoph Zwerschke <cito@online.de> writes:
> Yes, but it will complicate things. I will probably have to use 
> something like "configure" to do this. So far, this hasn't been 
> necessary. So I'd prefer a simple hack. Or how would you to this?

If you need to deal with more than one version of underlying code,
it's time to learn to use configure ...

			regards, tom lane



^ permalink  raw  reply  [nested|flat] 33+ messages in thread

* Re: Finding the pqlib version
@ 2006-02-11 17:40  Bruce Momjian <pgman@candle.pha.pa.us>
  parent: Christoph Zwerschke <cito@online.de>
  2 siblings, 1 reply; 33+ messages in thread

From: Bruce Momjian @ 2006-02-11 17:40 UTC (permalink / raw)
  To: Christoph Zwerschke <cito@online.de>; +Cc: pgsql-interfaces

Christoph Zwerschke wrote:
> Peter Eisentraut wrote:
> > You should query the presence of the function, not the version of the 
> > library.
> 
> Yes, but it will complicate things. I will probably have to use 
> something like "configure" to do this. So far, this hasn't been 
> necessary. So I'd prefer a simple hack. Or how would you to this?

I was wondering that myself.  I am thinking you would need to use
dlopen() to check for the symbol.  Because the libpq version could
change after you compile, I can't see how you could make it a configure
check unless you said you don't allow changes to libpq after the build.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073



^ permalink  raw  reply  [nested|flat] 33+ messages in thread

* Re: Finding the pqlib version
@ 2006-02-11 19:39  Peter Eisentraut <peter_e@gmx.net>
  parent: Christoph Zwerschke <cito@online.de>
  2 siblings, 2 replies; 33+ messages in thread

From: Peter Eisentraut @ 2006-02-11 19:39 UTC (permalink / raw)
  To: pgsql-interfaces; +Cc: Christoph Zwerschke <cito@online.de>

Christoph Zwerschke wrote:
> Yes, but it will complicate things. I will probably have to use
> something like "configure" to do this. So far, this hasn't been
> necessary. So I'd prefer a simple hack. Or how would you to this?

If you use distutils you can use the has_function method.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/



^ permalink  raw  reply  [nested|flat] 33+ messages in thread

* Re: Finding the pqlib version
@ 2006-02-11 21:29  Christoph Zwerschke <cito@online.de>
  parent: Peter Eisentraut <peter_e@gmx.net>
  1 sibling, 1 reply; 33+ messages in thread

From: Christoph Zwerschke @ 2006-02-11 21:29 UTC (permalink / raw)
  To: pgsql-interfaces

Peter Eisentraut wrote:
 > If you use distutils you can use the has_function method.

Ok. That could be an alternative to using configure.

-- Christoph



^ permalink  raw  reply  [nested|flat] 33+ messages in thread

* Re: Finding the pqlib version
@ 2006-02-12 00:01  Christoph Zwerschke <cito@online.de>
  parent: Bruce Momjian <pgman@candle.pha.pa.us>
  0 siblings, 1 reply; 33+ messages in thread

From: Christoph Zwerschke @ 2006-02-12 00:01 UTC (permalink / raw)
  To: pgsql-interfaces

Bruce Momjian wrote:
 > I was wondering that myself.  I am thinking you would need to use
 > dlopen() to check for the symbol.  Because the libpq version could
 > change after you compile, I can't see how you could make it a
 > configure check unless you said you don't allow changes to libpq
 > after the build.

The situation I was talking about is that you have a pre-compiled Python 
and PostgreSQL installed on your system, together with their header 
files, but you do not have the full source of Python and PostgreSQL 
available. I want to be able to compile PyGreSQL as a Python extension 
which is using functions from the python.dll and the libpq.dll, assuming 
that the installed header files match the installed dlls.

-- Christoph




^ permalink  raw  reply  [nested|flat] 33+ messages in thread

* Re: Finding the pqlib version
@ 2006-02-12 00:08  Christoph Zwerschke <cito@online.de>
  parent: Peter Eisentraut <peter_e@gmx.net>
  1 sibling, 0 replies; 33+ messages in thread

From: Christoph Zwerschke @ 2006-02-12 00:08 UTC (permalink / raw)
  To: pgsql-interfaces

Peter Eisentraut wrote:
> If you use distutils you can use the has_function method.

Yes, after experimenting a little bit with distutils, I think that's the 
way to go for PyGreSQL. I can check with has_function first and then 
give a hint to the precompiler using define_macros. Thanks.

-- Christoph



^ permalink  raw  reply  [nested|flat] 33+ messages in thread

* Re: Finding the pqlib version
@ 2006-02-12 01:01  Bruce Momjian <pgman@candle.pha.pa.us>
  parent: Christoph Zwerschke <cito@online.de>
  0 siblings, 0 replies; 33+ messages in thread

From: Bruce Momjian @ 2006-02-12 01:01 UTC (permalink / raw)
  To: Christoph Zwerschke <cito@online.de>; +Cc: pgsql-interfaces

Christoph Zwerschke wrote:
> Peter Eisentraut wrote:
>  > If you use distutils you can use the has_function method.
> 
> Ok. That could be an alternative to using configure.

And better because it is a run-time check rather than compile time.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073



^ permalink  raw  reply  [nested|flat] 33+ messages in thread

* Re: Finding the pqlib version
@ 2006-02-12 01:58  Bruce Momjian <pgman@candle.pha.pa.us>
  parent: Christoph Zwerschke <cito@online.de>
  0 siblings, 1 reply; 33+ messages in thread

From: Bruce Momjian @ 2006-02-12 01:58 UTC (permalink / raw)
  To: Christoph Zwerschke <cito@online.de>; +Cc: pgsql-interfaces

Christoph Zwerschke wrote:
> Bruce Momjian wrote:
>  > I was wondering that myself.  I am thinking you would need to use
>  > dlopen() to check for the symbol.  Because the libpq version could
>  > change after you compile, I can't see how you could make it a
>  > configure check unless you said you don't allow changes to libpq
>  > after the build.
> 
> The situation I was talking about is that you have a pre-compiled Python 
> and PostgreSQL installed on your system, together with their header 
> files, but you do not have the full source of Python and PostgreSQL 
> available. I want to be able to compile PyGreSQL as a Python extension 
> which is using functions from the python.dll and the libpq.dll, assuming 
> that the installed header files match the installed dlls.

Right, but assume you want to distribute that binary to others who might
have a different version of libpq.  This is required by packagers and a
run-time test is best in those cases.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073



^ permalink  raw  reply  [nested|flat] 33+ messages in thread

* Re: Finding the pqlib version
@ 2006-02-12 09:19  Christoph Zwerschke <cito@online.de>
  parent: Bruce Momjian <pgman@candle.pha.pa.us>
  0 siblings, 0 replies; 33+ messages in thread

From: Christoph Zwerschke @ 2006-02-12 09:19 UTC (permalink / raw)
  To: pgsql-interfaces

Bruce Momjian wrote:
> Right, but assume you want to distribute that binary to others who might
> have a different version of libpq.  This is required by packagers and a
> run-time test is best in those cases.

Right. I see the point now: It makes a difference whether you want to 
create a redistributable binary package that would run on older systems 
or whether you want the package to be compileable on older systems.

-- Christoph



^ permalink  raw  reply  [nested|flat] 33+ messages in thread

* Re: Finding the pqlib version
@ 2006-02-14 12:39  Murray Cumming <murrayc@murrayc.com>
  parent: Peter Eisentraut <peter_e@gmx.net>
  1 sibling, 1 reply; 33+ messages in thread

From: Murray Cumming @ 2006-02-14 12:39 UTC (permalink / raw)
  To: Peter Eisentraut <peter_e@gmx.net>; +Cc: pgsql-interfaces@postgresql.org, Christoph Zwerschke <cito@online.de>

On Sat, 2006-02-11 at 14:50 +0100, Peter Eisentraut wrote:
> Christoph Zwerschke wrote:
> > However, there is no such thing as "PQLIB_VERSION_MAJOR".
> > Anything else I could query instead?
> 
> You should query the presence of the function, not the version of the 
> library.

If pqlib installed a pkg-config .pc file then this would be simpler.

-- 
Murray Cumming
murrayc@murrayc.com
www.murrayc.com
www.openismus.com




^ permalink  raw  reply  [nested|flat] 33+ messages in thread

* Re: Finding the pqlib version
@ 2006-02-14 12:45  Christoph Zwerschke <cito@online.de>
  parent: Murray Cumming <murrayc@murrayc.com>
  0 siblings, 1 reply; 33+ messages in thread

From: Christoph Zwerschke @ 2006-02-14 12:45 UTC (permalink / raw)
  To: pgsql-interfaces

Murray Cumming wrote:
> On Sat, 2006-02-11 at 14:50 +0100, Peter Eisentraut wrote:
>> Christoph Zwerschke wrote:
>>> However, there is no such thing as "PQLIB_VERSION_MAJOR".
>>> Anything else I could query instead?
>> You should query the presence of the function, not the version of the 
>> library.
> 
> If pqlib installed a pkg-config .pc file then this would be simpler.

Yes. You could use pg_config, but this is usually only included in the 
server package, not in the libs package.

-- Christoph



^ permalink  raw  reply  [nested|flat] 33+ messages in thread

* Re: Finding the pqlib version
@ 2006-02-14 20:48  Peter Eisentraut <peter_e@gmx.net>
  parent: Christoph Zwerschke <cito@online.de>
  0 siblings, 1 reply; 33+ messages in thread

From: Peter Eisentraut @ 2006-02-14 20:48 UTC (permalink / raw)
  To: pgsql-interfaces; +Cc: Christoph Zwerschke <cito@online.de>

Christoph Zwerschke wrote:
> Yes. You could use pg_config, but this is usually only included in
> the server package, not in the libs package.

Example?

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/



^ permalink  raw  reply  [nested|flat] 33+ messages in thread

* Re: Finding the pqlib version
@ 2006-02-14 21:30  Christoph Zwerschke <cito@online.de>
  parent: Peter Eisentraut <peter_e@gmx.net>
  0 siblings, 1 reply; 33+ messages in thread

From: Christoph Zwerschke @ 2006-02-14 21:30 UTC (permalink / raw)
  To: pgsql-interfaces

Peter Eisentraut wrote:
> Christoph Zwerschke wrote:
>> Yes. You could use pg_config, but this is usually only included in
>> the server package, not in the libs package.
> 
> Example?

The Windwows installer. pg_config is installed with the "database 
server" feature, not with the "libs" feature. For Linux I was wrong, 
it's in the devel package, not in server.

-- Christoph



^ permalink  raw  reply  [nested|flat] 33+ messages in thread

* Re: Finding the pqlib version
@ 2006-02-14 22:31  Peter Eisentraut <peter_e@gmx.net>
  parent: Christoph Zwerschke <cito@online.de>
  0 siblings, 1 reply; 33+ messages in thread

From: Peter Eisentraut @ 2006-02-14 22:31 UTC (permalink / raw)
  To: pgsql-interfaces; +Cc: Christoph Zwerschke <cito@online.de>

Christoph Zwerschke wrote:
> The Windwows installer. pg_config is installed with the "database
> server" feature, not with the "libs" feature. For Linux I was wrong,
> it's in the devel package, not in server.

That should be reported as a bug to the installer people.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/



^ permalink  raw  reply  [nested|flat] 33+ messages in thread

* Re: Finding the pqlib version
@ 2006-02-14 23:02  Christoph Zwerschke <cito@online.de>
  parent: Peter Eisentraut <peter_e@gmx.net>
  0 siblings, 2 replies; 33+ messages in thread

From: Christoph Zwerschke @ 2006-02-14 23:02 UTC (permalink / raw)
  To: pgsql-interfaces

Peter Eisentraut wrote:
 > Christoph Zwerschke wrote:
 >> The Windwows installer. pg_config is installed with the "database
 >> server" feature, not with the "libs" feature. For Linux I was wrong,
 >> it's in the devel package, not in server.
 >
 > That should be reported as a bug to the installer people.

Which do you think would be the right package/feature category for 
pg_config for Linux/Windows? devel and Development->Tools/utilities?

-- Christoph



^ permalink  raw  reply  [nested|flat] 33+ messages in thread

* Re: Finding the pqlib version
@ 2006-02-15 09:56  Murray Cumming <murrayc@murrayc.com>
  parent: Christoph Zwerschke <cito@online.de>
  1 sibling, 1 reply; 33+ messages in thread

From: Murray Cumming @ 2006-02-15 09:56 UTC (permalink / raw)
  To: Christoph Zwerschke <cito@online.de>; +Cc: pgsql-interfaces

On Wed, 2006-02-15 at 00:02 +0100, Christoph Zwerschke wrote:
> Peter Eisentraut wrote:
>  > Christoph Zwerschke wrote:
>  >> The Windwows installer. pg_config is installed with the "database
>  >> server" feature, not with the "libs" feature. For Linux I was wrong,
>  >> it's in the devel package, not in server.
>  >
>  > That should be reported as a bug to the installer people.
> 
> Which do you think would be the right package/feature category for 
> pg_config for Linux/Windows? devel and Development->Tools/utilities?

I'm not sure what pg_config is. Maybe you are talking about something
else. I am talking about pkg-config:

http://pkgconfig.freedesktop.org/wiki/
http://www.openismus.com/documents/linux/using_libraries/using_libraries.shtml#cflagsandlibs

It's very easy to provide it and it's easy to use. It's already hugely
popular and used.

-- 
Murray Cumming
murrayc@murrayc.com
www.murrayc.com
www.openismus.com




^ permalink  raw  reply  [nested|flat] 33+ messages in thread

* Re: Finding the pqlib version
@ 2006-02-15 10:25  Peter Eisentraut <peter_e@gmx.net>
  parent: Christoph Zwerschke <cito@online.de>
  1 sibling, 1 reply; 33+ messages in thread

From: Peter Eisentraut @ 2006-02-15 10:25 UTC (permalink / raw)
  To: pgsql-interfaces; +Cc: Christoph Zwerschke <cito@online.de>

Christoph Zwerschke wrote:
> Which do you think would be the right package/feature category for
> pg_config for Linux/Windows? devel and Development->Tools/utilities?

I'm not sure what these categories are supposed to mean but they don't 
sound wrong.  To gauge the correct placement I would say that whenever 
you install libpq-fe.h you should get pg_config in the same 
package/module/installation.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/



^ permalink  raw  reply  [nested|flat] 33+ messages in thread

* Re: Finding the pqlib version
@ 2006-02-15 10:41  Christoph Zwerschke <cito@online.de>
  parent: Peter Eisentraut <peter_e@gmx.net>
  0 siblings, 0 replies; 33+ messages in thread

From: Christoph Zwerschke @ 2006-02-15 10:41 UTC (permalink / raw)
  To: pgsql-interfaces

Peter Eisentraut wrote:
 > Christoph Zwerschke wrote:
 >> Which do you think would be the right package/feature category for
 >> pg_config for Linux/Windows? devel and Development->Tools/utilities?
 >
 > I'm not sure what these categories are supposed to mean but they don't
 > sound wrong.  To gauge the correct placement I would say that whenever
 > you install libpq-fe.h you should get pg_config in the same
 > package/module/installation.

The problem is that the Windows installer has the "Development" feature 
subdivided into "Include files", "Library files", "PGXS files" and 
"Tools and utilities". Installing pg_config along with the include files 
would be confusing in this case.

By the way, putting the "Library files" under "Development" seems a bit 
unlucky, too. It should be on the top level instead. Where should such a 
suggestion be sent to? pgsql-patches?

-- Christoph




^ permalink  raw  reply  [nested|flat] 33+ messages in thread

* Re: Finding the pqlib version
@ 2006-02-15 10:49  Christoph Zwerschke <cito@online.de>
  parent: Murray Cumming <murrayc@murrayc.com>
  0 siblings, 0 replies; 33+ messages in thread

From: Christoph Zwerschke @ 2006-02-15 10:49 UTC (permalink / raw)
  To: pgsql-interfaces

Murray Cumming wrote:
 > Christoph Zwerschke wrote:
 >> Which do you think would be the right package/feature category for
 >> pg_config for Linux/Windows? devel and Development->Tools/utilities?
 >
 > I'm not sure what pg_config is. Maybe you are talking about something
 > else. I am talking about pkg-config:

pg_config is a PostgreSQL specific utility for roughly the same purpose:
http://www.postgresql.org/docs/8.1/interactive/app-pgconfig.html
So actually you don't need pkg-config here.

-- Christoph



^ permalink  raw  reply  [nested|flat] 33+ messages in thread

* Re: Finding the pqlib version
@ 2006-02-21 13:40  Magnus Hagander <mha@sollentuna.net>
  0 siblings, 1 reply; 33+ messages in thread

From: Magnus Hagander @ 2006-02-21 13:40 UTC (permalink / raw)
  To: Christoph Zwerschke <cito@online.de>; pgsql-interfaces

>  >> Which do you think would be the right package/feature 
> category for  >> pg_config for Linux/Windows? devel and 
> Development->Tools/utilities?
>  >
>  > I'm not sure what these categories are supposed to mean 
> but they don't  > sound wrong.  To gauge the correct 
> placement I would say that whenever  > you install libpq-fe.h 
> you should get pg_config in the same  > package/module/installation.
> 
> The problem is that the Windows installer has the 
> "Development" feature subdivided into "Include files", 
> "Library files", "PGXS files" and "Tools and utilities". 
> Installing pg_config along with the include files would be 
> confusing in this case.
> 
> By the way, putting the "Library files" under "Development" 
> seems a bit unlucky, too. It should be on the top level 
> instead. Where should such a suggestion be sent to? pgsql-patches?

pginstaller-devel@pgfoundry.org - subscribe info on the project page
http://pgfoundry.org/projects/pginstaller.

Note that we can relatively easily put pg_config.exe under multiple
locations (in the tree - still in the bin directory, but install can be
triggered by different features). It just has to be made its own
component.

But I'm actually thinking we should perhaps put it as a base feature -
along with libpq, being installed as soon as you install any part at
all. Does that sound reasonable?

//Magnus



^ permalink  raw  reply  [nested|flat] 33+ messages in thread

* Re: Finding the pqlib version
@ 2006-02-21 20:22  Peter Eisentraut <peter_e@gmx.net>
  parent: Magnus Hagander <mha@sollentuna.net>
  0 siblings, 0 replies; 33+ messages in thread

From: Peter Eisentraut @ 2006-02-21 20:22 UTC (permalink / raw)
  To: pgsql-interfaces; +Cc: Magnus Hagander <mha@sollentuna.net>; Christoph Zwerschke <cito@online.de>

Magnus Hagander wrote:
> But I'm actually thinking we should perhaps put it as a base feature
> - along with libpq, being installed as soon as you install any part
> at all. Does that sound reasonable?

No.

As I said previously, pg_config really belongs together with the include 
files and the link libraries.  Perhaps the categories are not so well 
chosen altogether.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/



^ permalink  raw  reply  [nested|flat] 33+ messages in thread

* Re: Finding the pqlib version
@ 2006-02-21 20:38  Magnus Hagander <mha@sollentuna.net>
  0 siblings, 3 replies; 33+ messages in thread

From: Magnus Hagander @ 2006-02-21 20:38 UTC (permalink / raw)
  To: Peter Eisentraut <peter_e@gmx.net>; pgsql-interfaces; +Cc: Christoph Zwerschke <cito@online.de>

> > But I'm actually thinking we should perhaps put it as a base feature
> > - along with libpq, being installed as soon as you install 
> any part at 
> > all. Does that sound reasonable?
> 
> No.
> 
> As I said previously, pg_config really belongs together with 
> the include files and the link libraries. 

But what about things like pg_config --bindir, pg_config --version,
pg_config --sharedir etc - they are definitly usable even if you're not
developing C language server extensions, aren't they?


> Perhaps the categories are not so well chosen altogether.

That I can agree with :-) I beleive they were originally split so you
could change the directory used for each part. But I don't think we
allow that anymore.

What would ppl suggest? Put it all together as one feature? Or keep
grouping in part?

//Magnus



^ permalink  raw  reply  [nested|flat] 33+ messages in thread

* Re: Finding the pqlib version
@ 2006-02-21 22:34  Christoph Zwerschke <cito@online.de>
  parent: Magnus Hagander <mha@sollentuna.net>
  2 siblings, 0 replies; 33+ messages in thread

From: Christoph Zwerschke @ 2006-02-21 22:34 UTC (permalink / raw)
  To: pgsql-interfaces

>> Perhaps the categories are not so well chosen altogether.
> 
> That I can agree with :-) I beleive they were originally split so you
> could change the directory used for each part. But I don't think we
> allow that anymore.
> 
> What would ppl suggest? Put it all together as one feature? Or keep
> grouping in part?

Yes, before deciding on where pg_config is put under Windows, we should 
first consider whether the categories should be rearranged.

I think the fine granulation is ok, but if possible, the grouping in the 
Win installer should parallel the package categories under Unix on the 
first level. For instance, the libs are currently part of the devel 
category on Win, while they are a separate package on Unix.

And I think you are right, --bindir, --sharedir and --version are 
pg_config features that could be interesting for any installation, not 
only if you compile something using the header files.

-- Christoph



^ permalink  raw  reply  [nested|flat] 33+ messages in thread

* Re: Finding the pqlib version
@ 2006-02-21 23:17  Tom Lane <tgl@sss.pgh.pa.us>
  parent: Magnus Hagander <mha@sollentuna.net>
  2 siblings, 1 reply; 33+ messages in thread

From: Tom Lane @ 2006-02-21 23:17 UTC (permalink / raw)
  To: Magnus Hagander <mha@sollentuna.net>; +Cc: Peter Eisentraut <peter_e@gmx.net>; pgsql-interfaces@postgresql.org, "Christoph Zwerschke" <cito@online.de>

"Magnus Hagander" <mha@sollentuna.net> writes:
>> As I said previously, pg_config really belongs together with 
>> the include files and the link libraries. 

> But what about things like pg_config --bindir, pg_config --version,
> pg_config --sharedir etc - they are definitly usable even if you're not
> developing C language server extensions, aren't they?

Yes.  pg_config started as strictly support for add-on makefiles but
it's evolved into something more than that.  I'd vote for just dropping
it into the base package.

(Memo to self: should probably rearrange the Red Hat RPMs likewise.)

			regards, tom lane



^ permalink  raw  reply  [nested|flat] 33+ messages in thread

* Re: Finding the pqlib version
@ 2006-02-22 12:44  Peter Eisentraut <peter_e@gmx.net>
  parent: Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 1 reply; 33+ messages in thread

From: Peter Eisentraut @ 2006-02-22 12:44 UTC (permalink / raw)
  To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Magnus Hagander <mha@sollentuna.net>; pgsql-interfaces@postgresql.org, "Christoph Zwerschke" <cito@online.de>

Am Mittwoch, 22. Februar 2006 00:17 schrieb Tom Lane:
> Yes.  pg_config started as strictly support for add-on makefiles but
> it's evolved into something more than that.  I'd vote for just dropping
> it into the base package.
>
> (Memo to self: should probably rearrange the Red Hat RPMs likewise.)

What would be the base package in that?

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/



^ permalink  raw  reply  [nested|flat] 33+ messages in thread

* Re: Finding the pqlib version
@ 2006-02-22 12:44  Peter Eisentraut <peter_e@gmx.net>
  parent: Magnus Hagander <mha@sollentuna.net>
  2 siblings, 0 replies; 33+ messages in thread

From: Peter Eisentraut @ 2006-02-22 12:44 UTC (permalink / raw)
  To: Magnus Hagander <mha@sollentuna.net>; +Cc: pgsql-interfaces@postgresql.org, "Christoph Zwerschke" <cito@online.de>

Am Dienstag, 21. Februar 2006 21:38 schrieb Magnus Hagander:
> But what about things like pg_config --bindir, pg_config --version,
> pg_config --sharedir etc - they are definitly usable even if you're not
> developing C language server extensions, aren't they?

I can't imagine why.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/



^ permalink  raw  reply  [nested|flat] 33+ messages in thread

* Re: Finding the pqlib version
@ 2006-02-22 14:28  Tom Lane <tgl@sss.pgh.pa.us>
  parent: Peter Eisentraut <peter_e@gmx.net>
  0 siblings, 0 replies; 33+ messages in thread

From: Tom Lane @ 2006-02-22 14:28 UTC (permalink / raw)
  To: Peter Eisentraut <peter_e@gmx.net>; +Cc: Magnus Hagander <mha@sollentuna.net>; pgsql-interfaces@postgresql.org, "Christoph Zwerschke" <cito@online.de>

Peter Eisentraut <peter_e@gmx.net> writes:
> Am Mittwoch, 22. Februar 2006 00:17 schrieb Tom Lane:
>> Yes.  pg_config started as strictly support for add-on makefiles but
>> it's evolved into something more than that.  I'd vote for just dropping
>> it into the base package.
>> 
>> (Memo to self: should probably rearrange the Red Hat RPMs likewise.)

> What would be the base package in that?

postgresql-nvr ... I wouldn't stick it in -libs if that's what you were
wondering.

			regards, tom lane



^ permalink  raw  reply  [nested|flat] 33+ messages in thread


end of thread, other threads:[~2006-02-22 14:28 UTC | newest]

Thread overview: 33+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2006-02-11 10:59 Finding the pqlib version Christoph Zwerschke <cito@online.de>
2006-02-11 12:57 ` Greg Sabino Mullane <greg@turnstep.com>
2006-02-11 13:50 ` Peter Eisentraut <peter_e@gmx.net>
2006-02-11 15:44   ` Christoph Zwerschke <cito@online.de>
2006-02-11 17:39     ` Tom Lane <tgl@sss.pgh.pa.us>
2006-02-11 17:40     ` Bruce Momjian <pgman@candle.pha.pa.us>
2006-02-12 00:01       ` Christoph Zwerschke <cito@online.de>
2006-02-12 01:58         ` Bruce Momjian <pgman@candle.pha.pa.us>
2006-02-12 09:19           ` Christoph Zwerschke <cito@online.de>
2006-02-11 19:39     ` Peter Eisentraut <peter_e@gmx.net>
2006-02-11 21:29       ` Christoph Zwerschke <cito@online.de>
2006-02-12 01:01         ` Bruce Momjian <pgman@candle.pha.pa.us>
2006-02-12 00:08       ` Christoph Zwerschke <cito@online.de>
2006-02-14 12:39   ` Murray Cumming <murrayc@murrayc.com>
2006-02-14 12:45     ` Christoph Zwerschke <cito@online.de>
2006-02-14 20:48       ` Peter Eisentraut <peter_e@gmx.net>
2006-02-14 21:30         ` Christoph Zwerschke <cito@online.de>
2006-02-14 22:31           ` Peter Eisentraut <peter_e@gmx.net>
2006-02-14 23:02             ` Christoph Zwerschke <cito@online.de>
2006-02-15 09:56               ` Murray Cumming <murrayc@murrayc.com>
2006-02-15 10:49                 ` Christoph Zwerschke <cito@online.de>
2006-02-15 10:25               ` Peter Eisentraut <peter_e@gmx.net>
2006-02-15 10:41                 ` Christoph Zwerschke <cito@online.de>
2006-02-11 15:01 ` Bruce Momjian <pgman@candle.pha.pa.us>
2006-02-11 16:03   ` Christoph Zwerschke <cito@online.de>
2006-02-21 13:40 Re: Finding the pqlib version Magnus Hagander <mha@sollentuna.net>
2006-02-21 20:22 ` Peter Eisentraut <peter_e@gmx.net>
2006-02-21 20:38 Re: Finding the pqlib version Magnus Hagander <mha@sollentuna.net>
2006-02-21 22:34 ` Christoph Zwerschke <cito@online.de>
2006-02-21 23:17 ` Tom Lane <tgl@sss.pgh.pa.us>
2006-02-22 12:44   ` Peter Eisentraut <peter_e@gmx.net>
2006-02-22 14:28     ` Tom Lane <tgl@sss.pgh.pa.us>
2006-02-22 12:44 ` Peter Eisentraut <peter_e@gmx.net>

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox