On 08/30/2013 12:04 AM, Pavel Stehule wrote: > > > > 2013/8/29 David E. Wheeler <da...@justatheory.com > <mailto:da...@justatheory.com>> > > On Aug 29, 2013, at 2:48 PM, Andres Freund <and...@2ndquadrant.com > <mailto:and...@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Ü
