With 9.0 there is the new hex encoding for BYTEA, which is activated by
default.

libpq BEFORE 9.0 are not able to decode that encoding.

I am programming with Python, using psycopg2. When psycopg2 is linked with
libpq 9.0, everything works fine with hex-encoding; if psycopg2 is linked
with libpq < 9.0, decoding hex-encoded bytea fails (it stays hexencoded).

This happens because in default configuration psycopg2 calls the
libpq-decode-encoded-bytea function (which is the way it should be done).

Now I would love to have an additional check "is the used psycopg2 linked to
an advanced-enough libpq", to be able to set bytea_output to 'escape' if the
libpq is not worthy.

My question: Which way is available to query the linked libpq version?

My other option is to select 'something_that_gets_casted_to_bytea'::bytea,
and check the return value. BUT that requires a round-trip to the server....

Harald
--
GHUM GmbH
Harald Armin Massa
Spielberger Straße 49
70435 Stuttgart
0173/9409607

Amtsgericht Stuttgart, HRB 734971
-
persuadere.
et programmare

Search Discussions

  • Magnus Hagander at Oct 5, 2010 at 8:02 am

    On Tue, Oct 5, 2010 at 09:33, Massa, Harald Armin wrote:
    With 9.0 there is the new hex encoding for BYTEA, which is activated by
    default.
    libpq BEFORE 9.0 are not able to decode that encoding.
    I am programming with Python, using psycopg2. When psycopg2 is linked with
    libpq 9.0, everything works fine with hex-encoding; if psycopg2 is linked
    with libpq < 9.0, decoding hex-encoded bytea fails (it stays hexencoded).
    This happens because in default configuration psycopg2 calls the
    libpq-decode-encoded-bytea function (which is the way it should be done).
    Now I would love to have an additional check "is the used psycopg2 linked to
    an advanced-enough libpq", to be able to set bytea_output to 'escape' if the
    libpq is not worthy.
    My question: Which way is available to query the linked libpq version?
    My other option is to select 'something_that_gets_casted_to_bytea'::bytea,
    and check the return value. BUT that requires a round-trip to the server....
    You can try calling PQconninfoParse() on a connectino string that has
    applicationname= in it. That will fail on anything pre-9.0. Assuming
    there's a way to access that function through psycopg2.

    But it does outline that fact that it wouldn't suck to have a function
    in libpq returning the version so that application can check this at
    runtime - clearly it would also be useful when being linked "through"
    something like psycopg2.
  • Massa, Harald Armin at Dec 14, 2010 at 4:56 pm

    My question: Which way is available to query the linked libpq version?
    But it does outline that fact that it wouldn't suck to have a >function in libpq returning the version so that application can >check this at runtime - clearly it would also be useful when >being linked "through" something like psycopg2.
    did there something happen?

    happen as in "an addition of a function to libpq to query its version
    without a server roundtrip AFTER libpq has been linked into sth has
    been decided for / against"

    Harald


    --
    GHUM GmbH
    Harald Armin Massa
    Spielberger Straße 49
    70435 Stuttgart
    0173/9409607

    Amtsgericht Stuttgart, HRB 734971
    -
    persuadere.
    et programmare
  • Greg Sabino Mullane at Oct 5, 2010 at 2:32 pm
    My question: Which way is available to query the linked libpq version?
    That's information your driver should be supplying. For example, in
    Perl (DBD::Pg), you would say

    if ($dbh->{pg_lib_version} >= 90000) {

    I'd raise a bug with psycopg2 if it does not provide that information.

    - --
    Greg Sabino Mullane greg@turnstep.com
    PGP Key: 0x14964AC8 201010051030
    http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
  • Magnus Hagander at Oct 5, 2010 at 2:38 pm

    On Tue, Oct 5, 2010 at 16:32, Greg Sabino Mullane wrote:
    My question: Which way is available to query the linked libpq version?
    That's information your driver should be supplying. For example, in
    Perl (DBD::Pg), you would say

    if ($dbh->{pg_lib_version} >= 90000) {

    I'd raise a bug with psycopg2 if it does not provide that information.
    How does the driver figure it out?
  • Greg Sabino Mullane at Oct 5, 2010 at 3:33 pm

    if ($dbh->{pg_lib_version} >= 90000) {

    I'd raise a bug with psycopg2 if it does not provide that information.
    How does the driver figure it out?
    DBD::Pg parses pg_config --version, then passes the information
    to the C programs for directive fiddling. I certainly hope
    other drivers are doing the same, as libpq varies across
    major versions a good deal.

    - --
    Greg Sabino Mullane greg@turnstep.com
    PGP Key: 0x14964AC8 201010051132
    http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
  • Peter Geoghegan at Oct 5, 2010 at 3:52 pm

    On 5 October 2010 16:33, Greg Sabino Mullane wrote:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: RIPEMD160

    if ($dbh->{pg_lib_version} >= 90000) {

    I'd raise a bug with psycopg2 if it does not provide that information.
    How does the driver figure it out?
    DBD::Pg parses pg_config --version, then passes the information
    to the C programs for directive fiddling. I certainly hope
    other drivers are doing the same, as libpq varies across
    major versions a good deal.
    I would imagine that most libpq wrapping drivers use libpq's
    PQserverVersion(), which returns an integer that looks like 90000.


    --
    Regards,
    Peter Geoghegan
  • Greg Sabino Mullane at Oct 5, 2010 at 4:14 pm

    I would imagine that most libpq wrapping drivers use libpq's
    PQserverVersion(), which returns an integer that looks like 90000.
    Yeah, I'm familiar with that (I wrote it :) but it's not useful
    here for two reasons:

    1) It's not available on older versions

    2) It returns the *target* version, not the *compiled* version.
    In other words, it requires an existing PGconn object.

    - --
    Greg Sabino Mullane greg@turnstep.com
    End Point Corporation http://www.endpoint.com/
    PGP Key: 0x14964AC8 201010051212
    http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
  • Massa, Harald Armin at Oct 5, 2010 at 4:15 pm

    I would imagine that most libpq wrapping drivers use libpq's
    PQserverVersion(), which returns an integer that looks like 90000.

    exactly that is exposed as cn.server_version property of the psycopg2
    connection object; but it does not help, as a 8.4libpq happily connects to a
    9.0 server... for some values of happy :)

    Harald


    --
    GHUM GmbH
    Harald Armin Massa
    Spielberger Straße 49
    70435 Stuttgart
    0173/9409607

    Amtsgericht Stuttgart, HRB 734971
    -
    persuadere.
    et programmare
  • Tom Lane at Oct 5, 2010 at 4:41 pm

    Peter Geoghegan writes:
    On 5 October 2010 16:33, Greg Sabino Mullane wrote:
    How does the driver figure it out?
    DBD::Pg parses pg_config --version, then passes the information
    to the C programs for directive fiddling. I certainly hope
    other drivers are doing the same, as libpq varies across
    major versions a good deal.
    I would imagine that most libpq wrapping drivers use libpq's
    PQserverVersion(), which returns an integer that looks like 90000.
    The real problem is that neither of these can be trusted to tell you the
    *library* version. PQserverVersion() is something else altogether,
    and I wouldn't want to assume that pg_config exactly matches the library
    you're linked to --- if it's even present at all.

    We could add a PQlibpqVersion(), maybe, but it would be many years
    before client code could rely on that being present.

    regards, tom lane
  • Magnus Hagander at Oct 5, 2010 at 4:56 pm

    On Tue, Oct 5, 2010 at 18:41, Tom Lane wrote:
    Peter Geoghegan <peter.geoghegan86@gmail.com> writes:
    On 5 October 2010 16:33, Greg Sabino Mullane wrote:
    How does the driver figure it out?
    DBD::Pg parses pg_config --version, then passes the information
    to the C programs for directive fiddling. I certainly hope
    other drivers are doing the same, as libpq varies across
    major versions a good deal.
    I would imagine that most libpq wrapping drivers use libpq's
    PQserverVersion(), which returns an integer that looks like 90000.
    The real problem is that neither of these can be trusted to tell you the
    *library* version.  PQserverVersion() is something else altogether,
    and I wouldn't want to assume that pg_config exactly matches the library
    you're linked to --- if it's even present at all.

    We could add a PQlibpqVersion(), maybe, but it would be many years
    before client code could rely on that being present.
    I think we should.

    And in a small way they can already - if they check for it
    dynamically, they'll know if it was 9.1 or newer at least :-) It'll be
    a long time before it's *easy* to use though. But if we don't add it
    now, it'll be even longer...
  • Massa, Harald Armin at Oct 5, 2010 at 5:42 pm

    We could add a PQlibpqVersion(), maybe, but it would be many years
    before client code could rely on that being present.
    I think we should.

    And in a small way they can already - if they check for it
    dynamically, they'll know if it was 9.1 or newer at least :-) It'll be
    a long time before it's *easy* to use though. But if we don't add it
    now, it'll be even longer...

    and an additional argument: Isn't it a wise decision for clients, to allways
    use the newset libpq, independent of the server? As younger libpqs happily
    connect to older servers AND are supposed to have less bugs.

    As libpq is very small, can be statically linked into applications and there
    are no license troubles, I can see no argument to use something that is not
    brand new... (compared to other databases with 120megabyte clients with
    longer licence restrictions than documentations...)

    Or am I missing sth?

    Harald


    --
    GHUM GmbH
    Harald Armin Massa
    Spielberger Straße 49
    70435 Stuttgart
    0173/9409607

    Amtsgericht Stuttgart, HRB 734971
    -
    persuadere.
    et programmare
  • Greg Sabino Mullane at Oct 5, 2010 at 8:39 pm

    The real problem is that neither of these can be trusted to tell you the
    *library* version. PQserverVersion() is something else altogether,
    and I wouldn't want to assume that pg_config exactly matches the library
    you're linked to --- if it's even present at all.
    Er...yes it will match exact...because we[1] get the location of the
    library files from pg_config as well. :) Handy little utility that.

    [1] DBD::Pg


    - --
    Greg Sabino Mullane greg@turnstep.com
    End Point Corporation http://www.endpoint.com/
    PGP Key: 0x14964AC8 201010051638
    http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
  • Magnus Hagander at Oct 5, 2010 at 8:44 pm

    On Tue, Oct 5, 2010 at 22:39, Greg Sabino Mullane wrote:
    The real problem is that neither of these can be trusted to tell you the
    *library* version.  PQserverVersion() is something else altogether,
    and I wouldn't want to assume that pg_config exactly matches the library
    you're linked to --- if it's even present at all.
    Er...yes it will match exact...because we[1] get the location of the
    library files from pg_config as well. :) Handy little utility that.
    How do you get pg_config to tell you which of the multiple versions of
    libpq that may be installed on the machine you are actually linking
    against?
  • Greg Sabino Mullane at Oct 5, 2010 at 8:53 pm

    Er...yes it will match exact...because we[1] get the location of the
    library files from pg_config as well. :) Handy little utility that.
    How do you get pg_config to tell you which of the multiple versions of
    libpq that may be installed on the machine you are actually linking
    against?
    Not sure what you mean. pg_config *drives* the compilation and linking,
    we don't blindly compile and simply take pg_config's word for it.
    pg_config --libdir and pg_config --includedir.

    - --
    Greg Sabino Mullane greg@turnstep.com
    End Point Corporation http://www.endpoint.com/
    PGP Key: 0x14964AC8 201010051651
    http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
  • Magnus Hagander at Oct 5, 2010 at 9:10 pm

    On Tue, Oct 5, 2010 at 22:53, Greg Sabino Mullane wrote:
    Er...yes it will match exact...because we[1] get the location of the
    library files from pg_config as well. :) Handy little utility that.
    How do you get pg_config to tell you which of the multiple versions of
    libpq that may be installed on the machine you are actually linking
    against?
    Not sure what you mean. pg_config *drives* the compilation and linking,
    we don't blindly compile and simply take pg_config's word for it.
    pg_config --libdir and pg_config --includedir.
    But that's build-time, not run-time.
  • Greg Sabino Mullane at Oct 6, 2010 at 12:17 pm

    Not sure what you mean. pg_config *drives* the compilation and linking,
    we don't blindly compile and simply take pg_config's word for it.
    pg_config --libdir and pg_config --includedir.
    But that's build-time, not run-time.
    Correct, not sure of your point. Is this a problem? Build-time is
    what we want here (determining the libpq we were built with)

    - --
    Greg Sabino Mullane greg@turnstep.com
    End Point Corporation http://www.endpoint.com/
    PGP Key: 0x14964AC8 201010060816
    http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
  • Magnus Hagander at Oct 6, 2010 at 12:25 pm

    On Wed, Oct 6, 2010 at 14:17, Greg Sabino Mullane wrote:
    Not sure what you mean. pg_config *drives* the compilation and linking,
    we don't blindly compile and simply take pg_config's word for it.
    pg_config --libdir and pg_config --includedir.
    But that's build-time, not run-time.
    Correct, not sure of your point. Is this a problem? Build-time is
    what we want here (determining the libpq we were built with)
    The original question was how to find this out from python, which
    means at runtime.

    And the pg_lib_version of DBD::Pg clearly doesn't tell you what
    version of libpq it's using, only what it was built against.

    As long as you have libpq 9.0, you can decode the bytea hex thingy,
    irregardless of what version of libpq your <whatever other
    code/library> was linked against.
  • Tom Lane at Oct 6, 2010 at 1:54 pm

    Magnus Hagander writes:
    On Wed, Oct 6, 2010 at 14:17, Greg Sabino Mullane wrote:
    But that's build-time, not run-time.
    Correct, not sure of your point. Is this a problem? Build-time is
    what we want here (determining the libpq we were built with)
    The original question was how to find this out from python, which
    means at runtime.
    And the pg_lib_version of DBD::Pg clearly doesn't tell you what
    version of libpq it's using, only what it was built against.
    As long as you have libpq 9.0, you can decode the bytea hex thingy,
    irregardless of what version of libpq your <whatever other
    code/library> was linked against.
    The problem here is that you might actually be *running* with a
    different version of libpq than you built against. This is actually
    highly likely if you distribute an executable that dynamically links
    to a shared library at runtime. And the dynamic linker will take any
    version of libpq.so that has the same major number, meaning that you
    cannot assume that it's not 8.4 just because you built against 9.0.

    regards, tom lane
  • Magnus Hagander at Oct 6, 2010 at 2:05 pm

    On Wed, Oct 6, 2010 at 15:54, Tom Lane wrote:
    Magnus Hagander <magnus@hagander.net> writes:
    On Wed, Oct 6, 2010 at 14:17, Greg Sabino Mullane wrote:
    But that's build-time, not run-time.
    Correct, not sure of your point. Is this a problem? Build-time is
    what we want here (determining the libpq we were built with)
    The original question was how to find this out from python, which
    means at runtime.
    And the pg_lib_version of DBD::Pg clearly doesn't tell you what
    version of libpq it's using, only what it was built against.
    As long as you have libpq 9.0, you can decode the bytea hex thingy,
    irregardless of what version of libpq your <whatever other
    code/library> was linked against.
    The problem here is that you might actually be *running* with a
    different version of libpq than you built against.  This is actually
    highly likely if you distribute an executable that dynamically links
    to a shared library at runtime.  And the dynamic linker will take any
    version of libpq.so that has the same major number, meaning that you
    cannot assume that it's not 8.4 just because you built against 9.0.
    Uh, that's what I was saying. The build version is quite irrelevant for that.

    Not to mention when you're on windows (and I dunno if any other
    platforms are like *that*), where they're all libpq.dll and we'll
    happily take *any* other libpq.dll (even an older one, but that will
    give you an error if you're actually using any functions not present
    in it).
  • Massa, Harald Armin at Oct 14, 2010 at 10:15 am

    And the dynamic linker will take any version of libpq.so that has the same
    major number, meaning that you
    cannot assume that it's not 8.4 just because you built against 9.0.

    [...]
    Not to mention when you're on windows (and I dunno if any other
    platforms are like *that*), where they're all libpq.dll and we'll
    happily take *any* other libpq.dll (even an older one, but that will give
    you an error if you're actually using any functions not present in it).

    So there are quite many arguments for adding a
    PQlibpqVersion()

    to libpq, yeah? Do you think you will do it, Magnus?

    [updates: the other "got bitten by the BYTEA-encoding-change"-thread is
    connected to this....]

    Best wishes,

    Harald

    --
    GHUM GmbH
    Harald Armin Massa
    Spielberger Straße 49
    70435 Stuttgart
    0173/9409607

    Amtsgericht Stuttgart, HRB 734971
    -
    persuadere.
    et programmare
  • Dmitriy Igrishin at Oct 14, 2010 at 12:01 pm
    Hey Massa,

    Again, I suggest PQlibVersion() or PQversion() instead of PQlibpqVersion().

    Why this "pq" redundancy in name? Waste of bytes.

    2010/10/14 Massa, Harald Armin <chef@ghum.de>
    And the dynamic linker will take any version of libpq.so that has the same
    major number, meaning that you
    cannot assume that it's not 8.4 just because you built against 9.0.

    [...]
    Not to mention when you're on windows (and I dunno if any other
    platforms are like *that*), where they're all libpq.dll and we'll
    happily take *any* other libpq.dll (even an older one, but that will give
    you an error if you're actually using any functions not present in it).

    So there are quite many arguments for adding a
    PQlibpqVersion()

    to libpq, yeah? Do you think you will do it, Magnus?

    [updates: the other "got bitten by the BYTEA-encoding-change"-thread is
    connected to this....]

    Best wishes,

    Harald

    --
    GHUM GmbH
    Harald Armin Massa
    Spielberger Straße 49
    70435 Stuttgart
    0173/9409607

    Amtsgericht Stuttgart, HRB 734971
    -
    persuadere.
    et programmare


    --
    // Dmitriy.
  • Massa, Harald Armin at Oct 14, 2010 at 12:13 pm
    Dmitriy,
    Again, I suggest PQlibVersion() or PQversion() instead of PQlibpqVersion().

    Why this "pq" redundancy in name? Waste of bytes.

    the first PQ qualifies the name-space "those are PostgresQl functions".
    the library is called libpq, and we are explicitly asking for the version of
    libpq; not of any other library that may or may not be connected with libpq

    (in some compilations there is linkage to some system libraries, which have
    versions of their own. in other implementations there are wrappers around
    the libpq-libraray, which have their own version to. Oh, and there is
    open-ssl which may be mixed into the whole party)

    So 2 bytes of source-code / linker redundancy in times where smartphones
    sport 12Gigabyte should be payed....

    Harald
    --
    GHUM GmbH
    Harald Armin Massa
    Spielberger Straße 49
    70435 Stuttgart
    0173/9409607

    Amtsgericht Stuttgart, HRB 734971
    -
    persuadere.
    et programmare
  • Dmitriy Igrishin at Oct 14, 2010 at 12:17 pm
    2010/10/14 Massa, Harald Armin <chef@ghum.de>
    Dmitriy,
    Again, I suggest PQlibVersion() or PQversion() instead of
    PQlibpqVersion().

    Why this "pq" redundancy in name? Waste of bytes.

    the first PQ qualifies the name-space "those are PostgresQl functions".
    the library is called libpq, and we are explicitly asking for the version
    of libpq; not of any other library that may or may not be connected with
    libpq
    If "PQ" is "namespace", so PQlibVersion() will never conflict with other
    libraries.

    (in some compilations there is linkage to some system libraries, which have
    versions of their own. in other implementations there are wrappers around
    the libpq-libraray, which have their own version to. Oh, and there is
    open-ssl which may be mixed into the whole party)

    So 2 bytes of source-code / linker redundancy in times where smartphones
    sport 12Gigabyte should be payed....

    I don't worry about source-code or linker. I want correctness.
    Why libpq does not have PQlibpqConnect() ? How about other libraries linked
    to libpq ?
    Waste of bytes.

    Harald
    --
    GHUM GmbH
    Harald Armin Massa
    Spielberger Straße 49
    70435 Stuttgart
    0173/9409607

    Amtsgericht Stuttgart, HRB 734971
    -
    persuadere.
    et programmare


    --
    // Dmitriy.
  • Tom Lane at Oct 5, 2010 at 9:00 pm

    "Greg Sabino Mullane" <greg@turnstep.com> writes:
    The real problem is that neither of these can be trusted to tell you the
    *library* version. PQserverVersion() is something else altogether,
    and I wouldn't want to assume that pg_config exactly matches the library
    you're linked to --- if it's even present at all.
    Er...yes it will match exact...because we[1] get the location of the
    library files from pg_config as well. :) Handy little utility that.
    [ shrug... ] It's not at all hard to think of scenarios where that will
    give you misleading results, even granted that you're willing to fall
    over when pg_config isn't present. But regardless of that, the
    technique simply isn't available to ordinary C code using the standard
    dynamic linker.

    regards, tom lane
  • Dmitriy Igrishin at Oct 5, 2010 at 8:41 pm
    Hey all,

    Could you call it as PQlibVersion() or even PQversion() instead of
    PQlibpqVersion() ?

    2010/10/5 Tom Lane <tgl@sss.pgh.pa.us>
    Peter Geoghegan <peter.geoghegan86@gmail.com> writes:
    On 5 October 2010 16:33, Greg Sabino Mullane wrote:
    How does the driver figure it out?
    DBD::Pg parses pg_config --version, then passes the information
    to the C programs for directive fiddling. I certainly hope
    other drivers are doing the same, as libpq varies across
    major versions a good deal.
    I would imagine that most libpq wrapping drivers use libpq's
    PQserverVersion(), which returns an integer that looks like 90000.
    The real problem is that neither of these can be trusted to tell you the
    *library* version. PQserverVersion() is something else altogether,
    and I wouldn't want to assume that pg_config exactly matches the library
    you're linked to --- if it's even present at all.

    We could add a PQlibpqVersion(), maybe, but it would be many years
    before client code could rely on that being present.

    regards, tom lane

    --
    Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
    To make changes to your subscription:
    http://www.postgresql.org/mailpref/pgsql-general


    --
    // Dmitriy.
  • Peter Eisentraut at Oct 7, 2010 at 9:23 am

    On tis, 2010-10-05 at 09:33 +0200, Massa, Harald Armin wrote:
    Now I would love to have an additional check "is the used psycopg2
    linked to an advanced-enough libpq", to be able to set bytea_output to
    'escape' if the libpq is not worthy.
    This is really something that psycopg2 should work out for you. I
    suggest you take up a discussion on this on their mailing list.
  • Devrim Gündüz at Oct 7, 2010 at 9:35 am

    On Thu, 2010-10-07 at 12:23 +0300, Peter Eisentraut wrote:
    This is really something that psycopg2 should work out for you. I
    suggest you take up a discussion on this on their mailing list.
    ...which is down over the last 3 weeks or so:

    http://www.initd.org/

    --
    Devrim GÜNDÜZ
    PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
    PostgreSQL RPM Repository: http://yum.pgrpms.org
    Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
    http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
  • A.M. at Oct 7, 2010 at 3:07 pm

    On Oct 7, 2010, at 5:34 AM, Devrim GÜNDÜZ wrote:
    On Thu, 2010-10-07 at 12:23 +0300, Peter Eisentraut wrote:
    This is really something that psycopg2 should work out for you. I
    suggest you take up a discussion on this on their mailing list.
    ...which is down over the last 3 weeks or so:

    http://www.initd.org/
    In addition, I posted a patch for 9.0 support which was supposed to be rolled in to psycopg2 weeks ago. Now I am stuck pushing my own psycopg2 egg around. The psycopg2 project is too reliant on one person (who has trouble managing his servers)- I wish he would move the project to a public project management service.

    I also remember a discussion on the poor state of postgresql drivers for python and which driver the PostgreSQL project should endorse- it looks like the situation has not improved. Here's the thread: http://archives.postgresql.org/pgsql-hackers/2010-02/msg00351.php

    Cheers,
    M
  • Bruce Momjian at Oct 20, 2010 at 11:26 pm

    A.M. wrote:
    On Oct 7, 2010, at 5:34 AM, Devrim G?ND?Z wrote:
    On Thu, 2010-10-07 at 12:23 +0300, Peter Eisentraut wrote:
    This is really something that psycopg2 should work out for you. I
    suggest you take up a discussion on this on their mailing list.
    ...which is down over the last 3 weeks or so:

    http://www.initd.org/
    In addition, I posted a patch for 9.0 support which was supposed to be
    rolled in to psycopg2 weeks ago. Now I am stuck pushing my own psycopg2
    egg around. The psycopg2 project is too reliant on one person (who has
    trouble managing his servers)- I wish he would move the project to a
    public project management service.

    I also remember a discussion on the poor state of postgresql drivers
    for python and which driver the PostgreSQL project should endorse- it
    looks like the situation has not improved. Here's the thread:
    http://archives.postgresql.org/pgsql-hackers/2010-02/msg00351.php
    The python driver situation did improve, for a while. :-|

    --
    Bruce Momjian <bruce@momjian.us> http://momjian.us
    EnterpriseDB http://enterprisedb.com

    + It's impossible for everything to be true. +

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-general @
categoriespostgresql
postedOct 5, '10 at 7:33a
activeDec 14, '10 at 4:56p
posts30
users10
websitepostgresql.org
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase