Re: PL/PgSQL STRICT - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: PL/PgSQL STRICT
Date
Msg-id 510BF731.5020802@gmx.net
Whole thread Raw
In response to Re: PL/PgSQL STRICT  ("Marko Tiikkaja" <pgmail@joh.to>)
Responses Re: PL/PgSQL STRICT  ("Marko Tiikkaja" <pgmail@joh.to>)
List pgsql-hackers
On 1/26/13 11:28 AM, Marko Tiikkaja wrote:
> On Fri, 21 Dec 2012 16:14:19 +0100, I wrote:
>> I wrote a patch
>> which allows you to add STRICT into PERFORM and INSERT/UPDATE/DELETE
>> without specifying an INTO clause.
> 
> Here's the second version of the patch, addressing the syntax issues.

I think the new syntax is horribly ugly.  The actual command name should
always come first, not options.  What will happen if people add more
options along this line?

> I also couldn't make the grammar work with PERFORM STRICT, so I allowed 
> STRICT SELECT  instead.

I don't quite understand the reason for distinguishing PERFORM and
SELECT, but what you are proposing will make this even more confusing.


That said, I don't quite believe in the premise for this patch to begin
with.  The supposed analogy is with INTO STRICT.  But that is
effectively a variable assignment and checks whether that assignment was
performed correctly.  So for scalar variables, this checks that exactly
one value was returned.  I'd imagine if we allowed a syntax like ...
INTO (a, b, c), (d, e, f) it would check that exactly two rows were
returned.  So this clause basically just ensures that the run-time
behavior is consistent with the appearance of the source code.

What you are now proposing is that STRICT means "one", but that's just
an opinion.  The SQL standard recognizes that updating or deleting
nothing is a noteworthy condition, so I could get partially behind this
patch if it just errored out when zero rows are affected, but insisting
on one is just arbitrary.

(Note also that elsewhere STRICT means something like "not null", so the
term is getting a bit overloaded.)




pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: obsolete code
Next
From: Bruce Momjian
Date:
Subject: Re: Turning auto-analyze off (was Re: [GENERAL] Unusually high IO for autovacuum worker)