Re: libpq confusion

From: Igor Korot <ikorot01(at)gmail(dot)com>
To: John R Pierce <pierce(at)hogranch(dot)com>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: libpq confusion
Date: 2017-09-20 17:47:05
Message-ID: CA+FnnTymh17F340HKugEzc2yv45MzyWNf4H2vZd2KuGOuOsUEA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Thx.
So it is referring to the command not a "command returning no data". ;-)

On Wed, Sep 20, 2017 at 1:42 PM, John R Pierce <pierce(at)hogranch(dot)com> wrote:
> On 9/20/2017 10:34 AM, Igor Korot wrote:
>
> >From the documentation:
> https://www.postgresql.org/docs/9.1/static/libpq-exec.html
>
> [quote]
> PGRES_COMMAND_OK
>
> Successful completion of a command returning no data.
> [/quote]
>
> No data = no rows, right?
>
> from that same page, a bit farther down, clarifying the potentially
> confusing wording.
>
> If the result status is PGRES_TUPLES_OK, then the functions described below
> can be used to retrieve the rows returned by the query. Note that a SELECT
> command that happens to retrieve zero rows still shows PGRES_TUPLES_OK.
> PGRES_COMMAND_OK is for commands that can never return rows (INSERT, UPDATE,
> etc.). A response of PGRES_EMPTY_QUERY might indicate a bug in the client
> software.
>
>
> --
> john r pierce, recycling bits in santa cruz

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Jerry Sievers 2017-09-20 18:00:34 Re: Up to date conventional wisdom re max shared_buffer size?
Previous Message John R Pierce 2017-09-20 17:42:08 Re: libpq confusion