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
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 |