Library names on Unix

It understand that on Windows a full installation will now provide two DLLs,
psqlodbca and psqlodbcw. With the Unix builds, we're still at the old scheme
of having a single psqlodbc library which can be built in one of two ways.
For binary packagers, this seems quite impractical. It seems best to change
to the -a and -w names as well, depending on which way you configured. (When
builidng a binary package, you just run the build process twice.) The only
slight concern about that would be that this breaks existing odbcinst.ini
files. Maybe one could discuss whether the -a or the -w variant provides the
most faithful backward compatibility, but I tend to think that users are
perhaps better served if they are forced to stop and decide with which
variant they want to proceed. Ideas?

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Re: Library names on Unix

=20

> -----Original Message-----
> From: pgsql-odbc-owner@postgresql.org=20
> [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Peter Eisentraut
> Sent: 02 January 2006 16:30
> To: pgsql-odbc@postgresql.org
> Subject: [ODBC] Library names on Unix
>=20
> Maybe one could discuss whether the -a or the -w=20
> variant provides the=20
> most faithful backward compatibility, but I tend to think=20
> that users are=20
> perhaps better served if they are forced to stop and decide=20
> with which=20
> variant they want to proceed. Ideas?

Agreed. That was the approach I took on Windows - rename 'em both and
force users to decide which one to use themselves.

BTW, if you're hacking the build system, would you mind adding a
--with-pgsql=3D option to configure? The current code you wrote relies on
pg_config being in the path which it certainly isn't on many of my
systems. I don't object to that being the default behaviour, but it
would be handy to override it when necessary.

Regards, Dave.


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Re: Library names on Unix

"Dave Page" writes:
> BTW, if you're hacking the build system, would you mind adding a
> --with-pgsql= option to configure? The current code you wrote relies on
> pg_config being in the path which it certainly isn't on many of my
> systems. I don't object to that being the default behaviour, but it
> would be handy to override it when necessary.

Agree about the usefulness, but --with-pgsql seems a too generic name in
this context (it could equally well refer to the location of a PG source
tree, say). How about something like
--with-pg-config=/opt/pgsql/bin/pg_config

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Re: Library names on Unix

Am Dienstag, 3. Januar 2006 09:41 schrieb Dave Page:
> BTW, if you're hacking the build system, would you mind adding a
> --with-pgsql= option to configure? The current code you wrote relies on
> pg_config being in the path which it certainly isn't on many of my
> systems.

The magic spell is configure PG_CONFIG=/path/pg_config. This is the same
mechanism by which you can override the path name of any other program in any
configure script.

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Re: Library names on Unix

=20

> -----Original Message-----
> From: Peter Eisentraut [mailto:peter_e@gmx.net]=20
> Sent: 04 January 2006 00:27
> To: Dave Page
> Cc: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] Library names on Unix
>=20
> Am Dienstag, 3. Januar 2006 09:41 schrieb Dave Page:
> > BTW, if you're hacking the build system, would you mind adding a
> > --with-pgsql=3D option to configure? The current code you=20
> wrote relies on
> > pg_config being in the path which it certainly isn't on many of my
> > systems.
>=20
> The magic spell is configure PG_CONFIG=3D/path/pg_config. This=20
> is the same=20
> mechanism by which you can override the path name of any=20
> other program in any=20
> configure script.

Thanks, but './configure --help' won't tell users that, nor is it
particularly consistent with other configure scripts which typically
offer options to specify the location of other code/libraries in
addition to having the undocumented ability to take things from the
environment. For example, we wouldn't expect users to configure the
location of SSL via an envvar when building the server.

Regards, Dave

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Re: Library names on Unix

Am Mittwoch, 4. Januar 2006 09:31 schrieb Dave Page:
> Thanks, but './configure --help' won't tell users that,

That is easy to add.

> nor is it
> particularly consistent with other configure scripts which typically
> offer options to specify the location of other code/libraries

As far as consistency goes, this behavior is consistent with other
PostgreSQL-using packages (that I have had a hand in), e.g., libpqxx. While
the dichotomy between options and variables is certainly not comprehensible
to the casual user, I'd hesitate to make up new stuff for the purpose of
spelling things differently. As long as it's documented, it should be OK.

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Re: Library names on Unix

=20

> -----Original Message-----
> From: Peter Eisentraut [mailto:peter_e@gmx.net]=20
> Sent: 04 January 2006 14:12
> To: Dave Page
> Cc: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] Library names on Unix
>=20
> As far as consistency goes, this behavior is consistent with other=20
> PostgreSQL-using packages (that I have had a hand in), e.g.,=20
> libpqxx.

And inconsistent with other PostgreSQL-using packages that I have a hand
in, e.g., pgAdmin :-)

> While=20
> the dichotomy between options and variables is certainly not=20
> comprehensible=20
> to the casual user, I'd hesitate to make up new stuff for the=20
> purpose of=20
> spelling things differently. As long as it's documented, it=20
> should be OK.

It seems to me it's not just a case of spelling things differently -
it's doing things the way users expect. I've *never* come across a
configure script that required me to set options via the environment
rather than a --with-foo=3D style option.

Regards, Dave.

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend