Hey all,

Is there way to determine failed connection attempt due to invalid
authorization (libpq)?

--
// Dmitriy.

Search Discussions

  • Robert Haas at Oct 17, 2010 at 2:32 am

    On Thu, Oct 14, 2010 at 2:59 PM, Dmitriy Igrishin wrote:
    Is there way to determine failed connection attempt due to invalid
    authorization (libpq)?
    I think this question would be more appropriate on pgsql-general. I
    suppose you would have to look at PQerrorMessage().

    --
    Robert Haas
    EnterpriseDB: http://www.enterprisedb.com
    The Enterprise PostgreSQL Company
  • Dmitriy Igrishin at Oct 17, 2010 at 6:03 am
    Hey Robert,

    I've asked pgsql-general.
    Unfortunately it seems that there is no better way to do it except
    parsing PQerrorMessage(). Sadly.


    2010/10/17 Robert Haas <[email protected]>
    On Thu, Oct 14, 2010 at 2:59 PM, Dmitriy Igrishin wrote:
    Is there way to determine failed connection attempt due to invalid
    authorization (libpq)?
    I think this question would be more appropriate on pgsql-general. I
    suppose you would have to look at PQerrorMessage().

    --
    Robert Haas
    EnterpriseDB: http://www.enterprisedb.com
    The Enterprise PostgreSQL Company


    --
    // Dmitriy.
  • Robert Haas at Oct 18, 2010 at 2:04 pm

    On Sun, Oct 17, 2010 at 2:03 AM, Dmitriy Igrishin wrote:
    I've asked pgsql-general.
    Unfortunately it seems that there is no better way to do it except
    parsing PQerrorMessage(). Sadly.
    Yeah, doesn't look like it. A quick glance at the code reveals that a
    PGresult can store individual error fields but a PGconn can store only
    a message. :-(

    --
    Robert Haas
    EnterpriseDB: http://www.enterprisedb.com
    The Enterprise PostgreSQL Company
  • David Fetter at Oct 18, 2010 at 2:06 pm

    On Mon, Oct 18, 2010 at 10:03:55AM -0400, Robert Haas wrote:
    On Sun, Oct 17, 2010 at 2:03 AM, Dmitriy Igrishin wrote:
    I've asked pgsql-general.
    Unfortunately it seems that there is no better way to do it except
    parsing PQerrorMessage(). Sadly.
    Yeah, doesn't look like it. A quick glance at the code reveals that a
    PGresult can store individual error fields but a PGconn can store only
    a message. :-(
    Does this seem worth patching for 9.1?

    Cheers,
    David.
    --
    David Fetter <[email protected]> http://fetter.org/
    Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
    Skype: davidfetter XMPP: [email protected]
    iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

    Remember to vote!
    Consider donating to Postgres: http://www.postgresql.org/about/donate
  • Robert Haas at Oct 18, 2010 at 2:18 pm

    On Mon, Oct 18, 2010 at 10:05 AM, David Fetter wrote:
    On Mon, Oct 18, 2010 at 10:03:55AM -0400, Robert Haas wrote:
    On Sun, Oct 17, 2010 at 2:03 AM, Dmitriy Igrishin wrote:
    I've asked pgsql-general.
    Unfortunately it seems that there is no better way to do it except
    parsing PQerrorMessage(). Sadly.
    Yeah, doesn't look like it.  A quick glance at the code reveals that a
    PGresult can store individual error fields but a PGconn can store only
    a message.   :-(
    Does this seem worth patching for 9.1?
    Please feel free to submit a patch if you have an idea how to solve it.

    --
    Robert Haas
    EnterpriseDB: http://www.enterprisedb.com
    The Enterprise PostgreSQL Company
  • David Fetter at Oct 18, 2010 at 2:26 pm

    On Mon, Oct 18, 2010 at 10:18:25AM -0400, Robert Haas wrote:
    On Mon, Oct 18, 2010 at 10:05 AM, David Fetter wrote:
    On Mon, Oct 18, 2010 at 10:03:55AM -0400, Robert Haas wrote:
    On Sun, Oct 17, 2010 at 2:03 AM, Dmitriy Igrishin wrote:
    I've asked pgsql-general.
    Unfortunately it seems that there is no better way to do it except
    parsing PQerrorMessage(). Sadly.
    Yeah, doesn't look like it.  A quick glance at the code reveals that a
    PGresult can store individual error fields but a PGconn can store only
    a message.   :-(
    Does this seem worth patching for 9.1?
    Please feel free to submit a patch if you have an idea how to solve it.
    Will look that over this evening and submit an idea for a patch :)

    Cheers,
    David.
    --
    David Fetter <[email protected]> http://fetter.org/
    Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
    Skype: davidfetter XMPP: [email protected]
    iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

    Remember to vote!
    Consider donating to Postgres: http://www.postgresql.org/about/donate
  • David Fetter at Oct 19, 2010 at 6:36 am

    On Mon, Oct 18, 2010 at 07:26:32AM -0700, David Fetter wrote:
    On Mon, Oct 18, 2010 at 10:18:25AM -0400, Robert Haas wrote:
    On Mon, Oct 18, 2010 at 10:05 AM, David Fetter wrote:
    On Mon, Oct 18, 2010 at 10:03:55AM -0400, Robert Haas wrote:
    On Sun, Oct 17, 2010 at 2:03 AM, Dmitriy Igrishin wrote:
    I've asked pgsql-general.
    Unfortunately it seems that there is no better way to do it except
    parsing PQerrorMessage(). Sadly.
    Yeah, doesn't look like it.  A quick glance at the code reveals that a
    PGresult can store individual error fields but a PGconn can store only
    a message.   :-(
    Does this seem worth patching for 9.1?
    Please feel free to submit a patch if you have an idea how to solve it.
    Will look that over this evening and submit an idea for a patch :)
    I'm pretty slammed by some other commitments at the moment. Probably
    won't get a chance to do this until at least this weekend.

    Cheers,
    David.
    --
    David Fetter <[email protected]> http://fetter.org/
    Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
    Skype: davidfetter XMPP: [email protected]
    iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

    Remember to vote!
    Consider donating to Postgres: http://www.postgresql.org/about/donate

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedOct 14, '10 at 6:59p
activeOct 19, '10 at 6:36a
posts8
users3
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2023 Grokbase