Re: [HACKERS] plpgsql - additional extra checks - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: [HACKERS] plpgsql - additional extra checks
Date
Msg-id CAFj8pRDUZ8u-hhf-Pm1q51x5DvnpUTMrz1CgMgh28XnrJxfsOQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] plpgsql - additional extra checks  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: [HACKERS] plpgsql - additional extra checks  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List pgsql-hackers


2018-03-16 2:46 GMT+01:00 Tomas Vondra <tomas.vondra@2ndquadrant.com>:
On 03/04/2018 07:07 PM, Pavel Stehule wrote:
>
> ...
>
> I am sending updated patch with Tomas changes
>

Seems 2cf8c7aa48 broke this patch, as it tweaked a number of regression
tests. Other than that, I think the patch is pretty much ready.

One minor detail is that this bit from exec_stmt_execsql doesn't seem
particularly readable:

errlevel = stmt->strict || stmt->mod_stmt ? ERROR : too_many_rows_level;
use_errhint = !(stmt->strict || stmt->mod_stmt);

I had to think for a while if "||" takes precedence over "?", so I'd
suggest adding some () around the first condition. But that makes it
pretty much just (!use_errhint) so perhaps something like

    bool force_error;

    force_error = (stmt->strict || stmt->mod_stmt);
    errlevel = force_error ? ERROR : too_many_rows_level;
    use_errhint = !force_error;

would be better?

good idea
 

Actually, now that I'm looking at this part of the code again, I see the
change from

    errmsg("query returned more than one row"),

to

    errmsg("SELECT INTO query returned more than one row"),

is probably bogus, because this also deals with stmt->mod_stmt, not just
strict SELECT INTO queries. So let's just revert to the old wording.

fixed
 

regards

--
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: segmentation fault in pg head with SQL function.
Next
From: Pavel Stehule
Date:
Subject: Re: missing support of named convention for procedures