Re: PL/pgSQL PERFORM with CTE

From: Hannu Krosing <hannu(at)2ndQuadrant(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: "David E(dot) Wheeler" <david(at)justatheory(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Marko Tiikkaja <marko(at)joh(dot)to>, Jan Wieck <JanWieck(at)yahoo(dot)com>, pgsql-hackers Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PL/pgSQL PERFORM with CTE
Date: 2013-08-29 23:28:17
Message-ID: 521FD911.2020202@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ants Aasma 2013-08-29 23:53:54 Re: WAL CPU overhead/optimization (was Master-slave visibility order)
Previous Message Andres Freund 2013-08-29 23:10:15 Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])