On Fri, 01 Feb 2013 18:11:13 +0100, Peter Eisentraut <peter_e@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