Re: PL/pgSQL PERFORM with CTE

2013/8/29 David E. Wheeler <david@justatheory.com>

On Aug 29, 2013, at 2:48 PM, Andres Freund <andres@2ndquadrant.com> wrote:

>> You have yet to supply any arguments which support this position.
>
> I am not convinced that's enough of a reason, but the requirement to use
> PERFORM for SELECTs that aren't stored anywhere actually has prevented
> bugs for me. I am not convinced that's worth the cost since I also have
> been annoyed by it several times, but it's not as crystal clear as you
> paint it.

So now we can revise Josh’s assertion to: “I have seen only tepid, unconvincing arguments which support this position.”

I have thought that PERFORM was useful to mark queries that discard results in the past, but I think now that the mental load is higher, even if it can be fixed with CTEs, it’s more trouble than it’s worth.

when we fix a correct call of VOID function, then half of problem goes out. Second half is subjective.

I remember, some years ago there was a proposal to change syntax and remove all verbosity features from PL/pgSQL - for example - using only END instead END IF, END LOOP, ...

This has a bit more value as it allows you to detect some (though not all) structural errors.

PERFORM just forces you to replace some SELECTs just to confirm
that you really did not want to capture the result.

If the original aim was somehow connected with allowing direct
function calls for PL/SQL compatibility, then why not just implement
direct function calls instead and let us have plain SELECT back ?

For me, this talk is similar - we have a language, that was designed be secure and verbose,

If you want a verbose expression for ignoring the result I'd suggest
something like "SELECT ... IGNORING RESULT" or "SELECT ... INTO VOID"
It is self-describing like most of SQL, instead of making you wander
each time if the word you want to replace SELECT with to ignore
the result was PERFORM or EXECUTE :)

But I can *not* see how allowing just SELECT and discarding the result has
any less "security", for any definition of security I can think of.

For me it is just an arbitrary nuisance, with which I can live, but I'd prefer not to.


Cheers

-- 
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ