On Fri, 01 Feb 2013 18:11:13 +0100, Peter Eisentraut <pete...@gmx.net>
wrote:
On 1/26/13 11:28 AM, Marko Tiikkaja wrote:
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?
WITH foo AS (..) SELECT ..; doesn't have the command first either.
I don't really see what other plpgsql-specific options we would add..
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.
Fine, I can see why you see it that way.
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.
*shrug*
To me, this makes the most sense. In my experience if you know something
should be there, it's exactly one row and not "one or more". Not throwing
an error on "more than one" would make this feature a lot less useful in
practice.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
