Thread

Commits

  1. Fix documentation for dblink_error_message() return value

  1. dblink_error_message return value

    The Post Office <noreply@postgresql.org> — 2018-08-08T09:16:24Z

    The following documentation comment has been logged on the website:
    
    Page: https://www.postgresql.org/docs/10/static/contrib-dblink-error-message.html
    Description:
    
    Documentation says:
    
    Return Value
    Returns last error message, or an empty string if there has been no error in
    this connection.
    
    Which is invalid.
    
    Actually it returns 'OK' string if no error was raised. Secondly
    dblink_is_busy must be first called to make dblink_error_message returns an
    error message. (Tested on 9.6.9)
    
  2. Re: dblink_error_message return value

    Tom Lane <tgl@sss.pgh.pa.us> — 2018-08-08T15:57:17Z

    =?utf-8?q?PG_Doc_comments_form?= <noreply@postgresql.org> writes:
    > The following documentation comment has been logged on the website:
    > Documentation says:
    
    > Return Value
    > Returns last error message, or an empty string if there has been no error in
    > this connection.
    > Which is invalid.
    > Actually it returns 'OK' string if no error was raised.
    
    Good catch!  The code's quite clear about it, but the SGML docs need
    fixed.
    
    > Secondly
    > dblink_is_busy must be first called to make dblink_error_message returns an
    > error message. (Tested on 9.6.9)
    
    Meh.  I see what you're getting at here, I think, but that seems like a
    completely wrong/misleading statement of the issue.  Joe, can you think of
    better phraseology?
    
    			regards, tom lane
    
    
    
  3. Re: dblink_error_message return value

    David G. Johnston <david.g.johnston@gmail.com> — 2018-08-08T16:58:43Z

    On Wed, Aug 8, 2018 at 8:57 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
    
    > > Secondly
    > > dblink_is_busy must be first called to make dblink_error_message returns
    > an
    > > error message. (Tested on 9.6.9)
    >
    > Meh.  I see what you're getting at here, I think, but that seems like a
    > completely wrong/misleading statement of the issue.  Joe, can you think of
    > better phraseology?
    >
    
    I would suggest that while rewording might be useful a more beneficial
    improvement would be separating the commands into "Sync/ASync" and link
    back into the corresponding libpq documentation sections which dblink
    provides direct SQL layer access to (and which the docs seem to have been
    written under the assumption the reader was knowledgeable of that API).  It
    does abstract away some of the material in the libpq docs but I think it
    would be a reasonable halfway measure in lieu of spending time enhancing
    the mostly obsolete dblink extension documentation.
    
    David J.
    
  4. Re: dblink_error_message return value

    Joe Conway <mail@joeconway.com> — 2018-09-25T17:50:11Z

    On 08/08/2018 11:57 AM, Tom Lane wrote:
    > =?utf-8?q?PG_Doc_comments_form?= <noreply@postgresql.org> writes:
    >> The following documentation comment has been logged on the website:
    >> Documentation says:
    > 
    >> Return Value
    >> Returns last error message, or an empty string if there has been no error in
    >> this connection.
    >> Which is invalid.
    >> Actually it returns 'OK' string if no error was raised.
    > 
    > Good catch!  The code's quite clear about it, but the SGML docs need
    > fixed.
    
    
    As mentioned on the nearby thread, will fix. I suppose this ought to be
    back-patched.
    
    
    >> Secondly
    >> dblink_is_busy must be first called to make dblink_error_message returns an
    >> error message. (Tested on 9.6.9)
    > 
    > Meh.  I see what you're getting at here, I think, but that seems like a
    > completely wrong/misleading statement of the issue.  Joe, can you think of
    > better phraseology?
    
    Maybe a note, something like this?
    ------------
    When asynchronous queries are initiated by dblink_send_query(), the
    error message associated with the connection might not get updated until
    the server's response message is consumed. This typically means that
    dblink_is_busy() or dblink_get_result() should be called prior to
    dblink_error_message(), so that any error generated by the asynchronous
    query() will be visible.
    ------------
    
    Joe
    
    -- 
    Crunchy Data - http://crunchydata.com
    PostgreSQL Support for Secure Enterprises
    Consulting, Training, & Open Source Development
    
    
  5. Re: dblink_error_message return value

    Joe Conway <mail@joeconway.com> — 2018-09-25T19:58:12Z

    On 09/25/2018 01:50 PM, Joe Conway wrote:
    > On 08/08/2018 11:57 AM, Tom Lane wrote:
    >> =?utf-8?q?PG_Doc_comments_form?= <noreply@postgresql.org> writes:
    >>> The following documentation comment has been logged on the website:
    >>> Documentation says:
    >> 
    >>> Return Value
    >>> Returns last error message, or an empty string if there has been no error in
    >>> this connection.
    >>> Which is invalid.
    >>> Actually it returns 'OK' string if no error was raised.
    >> 
    >> Good catch!  The code's quite clear about it, but the SGML docs need
    >> fixed.
    > 
    > 
    > As mentioned on the nearby thread, will fix. I suppose this ought to be
    > back-patched.
    > 
    > 
    >>> Secondly
    >>> dblink_is_busy must be first called to make dblink_error_message returns an
    >>> error message. (Tested on 9.6.9)
    >> 
    >> Meh.  I see what you're getting at here, I think, but that seems like a
    >> completely wrong/misleading statement of the issue.  Joe, can you think of
    >> better phraseology?
    > 
    > Maybe a note, something like this?
    > ------------
    > When asynchronous queries are initiated by dblink_send_query(), the
    > error message associated with the connection might not get updated until
    > the server's response message is consumed. This typically means that
    > dblink_is_busy() or dblink_get_result() should be called prior to
    > dblink_error_message(), so that any error generated by the asynchronous
    > query() will be visible.
    > ------------
    
    And now with the corresponding patch attached.
    
    Thoughts/comments?
    
    Joe
    -- 
    Crunchy Data - http://crunchydata.com
    PostgreSQL Support for Secure Enterprises
    Consulting, Training, & Open Source Development
    
  6. Re: dblink_error_message return value

    Joe Conway <mail@joeconway.com> — 2018-10-02T12:45:37Z

    On 09/25/2018 03:58 PM, Joe Conway wrote:
    > On 09/25/2018 01:50 PM, Joe Conway wrote:
    >> On 08/08/2018 11:57 AM, Tom Lane wrote:
    >>> =?utf-8?q?PG_Doc_comments_form?= <noreply@postgresql.org> writes:
    >>>> The following documentation comment has been logged on the website:
    >>>> Documentation says:
    >>> 
    >>>> Return Value
    >>>> Returns last error message, or an empty string if there has been no error in
    >>>> this connection.
    >>>> Which is invalid.
    >>>> Actually it returns 'OK' string if no error was raised.
    >>> 
    >>> Good catch!  The code's quite clear about it, but the SGML docs need
    >>> fixed.
    >> 
    >> 
    >> As mentioned on the nearby thread, will fix. I suppose this ought to be
    >> back-patched.
    >> 
    >> 
    >>>> Secondly
    >>>> dblink_is_busy must be first called to make dblink_error_message returns an
    >>>> error message. (Tested on 9.6.9)
    >>> 
    >>> Meh.  I see what you're getting at here, I think, but that seems like a
    >>> completely wrong/misleading statement of the issue.  Joe, can you think of
    >>> better phraseology?
    >> 
    >> Maybe a note, something like this?
    >> ------------
    >> When asynchronous queries are initiated by dblink_send_query(), the
    >> error message associated with the connection might not get updated until
    >> the server's response message is consumed. This typically means that
    >> dblink_is_busy() or dblink_get_result() should be called prior to
    >> dblink_error_message(), so that any error generated by the asynchronous
    >> query() will be visible.
    >> ------------
    > 
    > And now with the corresponding patch attached.
    > 
    > Thoughts/comments?
    
    
    Going once, going twice, ...
    (if no complaints will commit soon)
    
    Joe
    
    -- 
    Crunchy Data - http://crunchydata.com
    PostgreSQL Support for Secure Enterprises
    Consulting, Training, & Open Source Development
    
  7. Re: dblink_error_message return value

    Joe Conway <mail@joeconway.com> — 2019-02-17T18:19:56Z

    On 10/2/18 8:45 AM, Joe Conway wrote:
    > On 09/25/2018 03:58 PM, Joe Conway wrote:
    >> On 09/25/2018 01:50 PM, Joe Conway wrote:
    >>> On 08/08/2018 11:57 AM, Tom Lane wrote:
    >>>> =?utf-8?q?PG_Doc_comments_form?= <noreply@postgresql.org> writes:
    >>>>> The following documentation comment has been logged on the website:
    >>>>> Documentation says:
    >>>> 
    >>>>> Return Value
    >>>>> Returns last error message, or an empty string if there has been no error in
    >>>>> this connection.
    >>>>> Which is invalid.
    >>>>> Actually it returns 'OK' string if no error was raised.
    >>>> 
    >>>> Good catch!  The code's quite clear about it, but the SGML docs need
    >>>> fixed.
    >>> 
    >>> 
    >>> As mentioned on the nearby thread, will fix. I suppose this ought to be
    >>> back-patched.
    >>> 
    >>> 
    >>>>> Secondly
    >>>>> dblink_is_busy must be first called to make dblink_error_message returns an
    >>>>> error message. (Tested on 9.6.9)
    >>>> 
    >>>> Meh.  I see what you're getting at here, I think, but that seems like a
    >>>> completely wrong/misleading statement of the issue.  Joe, can you think of
    >>>> better phraseology?
    >>> 
    >>> Maybe a note, something like this?
    >>> ------------
    >>> When asynchronous queries are initiated by dblink_send_query(), the
    >>> error message associated with the connection might not get updated until
    >>> the server's response message is consumed. This typically means that
    >>> dblink_is_busy() or dblink_get_result() should be called prior to
    >>> dblink_error_message(), so that any error generated by the asynchronous
    >>> query() will be visible.
    >>> ------------
    >> 
    >> And now with the corresponding patch attached.
    >> 
    >> Thoughts/comments?
    > 
    > 
    > Going once, going twice, ...
    > (if no complaints will commit soon)
    
    
    Well, maybe not so soon,  but now done.
    
    Joe
    
    -- 
    Crunchy Data - http://crunchydata.com
    PostgreSQL Support for Secure Enterprises
    Consulting, Training, & Open Source Development