2016-04-10 17:49 GMT+02:00 David G. Johnston <david.g.johns...@gmail.com>:

> On Sun, Apr 10, 2016 at 1:13 AM, Pavel Stehule <pavel.steh...@gmail.com>
> wrote:
>> Hi
>> 2016-03-21 22:13 GMT+01:00 Pavel Stehule <pavel.steh...@gmail.com>:
>>> Hi
>>> 2016-03-21 21:24 GMT+01:00 Merlin Moncure <mmonc...@gmail.com>:
>>>> Patch is trivial (see below), discussion is not :-).
>>>> I see no useful reason to require INTO when returning data with
>>>> SELECT.  However, requiring queries to indicate not needing data via
>>>> PERFORM causes some annoyances:
>>>> *) converting routines back and forth between pl/pgsql and pl/sql
>>>> requires needless busywork and tends to cause errors to be thrown at
>>>> runtime
>>>> *) as much as possible, (keywords begin/end remain a problem),
>>>> pl/pgsql should be a superset of sql
>>>> *) it's much more likely to be burned by accidentally forgetting to
>>>> swap in PERFORM than to accidentally leave in a statement with no
>>>> actionable target.  Even if you did so in the latter case, it stands
>>>> to reason you'd accidentally leave in the target variable, too.
>>>> *) the PERFORM requirement hails from the days when only statements
>>>> starting with SELECT return data.  There is no PERFORM equivalent for
>>>> WITH/INSERT/DELETE/UPDATE and there are real world scenarios where you
>>>> might have a RETURNING clause that does something but not necessarily
>>>> want to place the result in a variable (for example passing to
>>>> volatile function).  Take a look at the errhint() clause below -- we
>>>> don't even have a suggestion in that case.
>>>> This has come up before, and there was a fair amount of sympathy for
>>>> this argument albeit with some dissent -- notably Pavel.  I'd like to
>>>> get a hearing on the issue -- thanks.  If we decide to move forward,
>>>> this would effectively deprecate PERFORM and the documentation will be
>>>> suitably modified as well.
>> here is another argument why this idea is not good.
>> http://stackoverflow.com/questions/36509511/error-query-has-no-destination-for-result-data-when-writing-pl-pgsql-function
>> Now, when people coming from T-SQL world use some T-SQL constructs, then
>> usually the code should not work with the error "query has not destination
>> for data ... "
>> When PLpgSQL will be more tolerant, then their code will be executed
>> without any error, but will not work.
> I would be inclined to require that DML returning tuples requires INTO
> while a SELECT does not.  Adding RETURNING is a deliberate user action that
> we can and probably should be conservative for.  Writing SELECT is default
> user behavior and is quite often used only for its side-effects.  Since SQL
> proper doesn't offer a means to distinguish between the two modes adding
> that distinction to pl/pgSQL, while useful, doesn't seem like something
> that has to be forced upon the user.

It doesn't help - SELECT is most often used construct.

We can be less strict for SELECT expr, but SELECT FROM should not be
allowed without INTO clause.

It is reason, why I dislike this proposal, because the rules when INTO is
allowed, required will be more complex. Now, the rules are pretty simple -
and it is safe for beginners. I accept so current behave should be limiting
for experts.



> On the last point I probably wouldn't bother to deprecate PERFORM for that
> reason, let alone the fact we likely would never choose to actually remove
> the capability.
> ​I'm not convinced that allowing RETURNING to be target-less is needed.
> With writable CTEs you can now get that capability by wrapping the DML in a
> target-less SELECT.  Again, coming back to "typical usage", I'd have no
> problem making something like "RETURNING func(col) INTO /dev/null" ​work
> for the exceptional cases that need returning but don't have any good
> variables to assign the values to and don't want to make some up just to
> ignore them.
> David J.

Reply via email to