Re: Relax requirement for INTO with SELECT in pl/pgsql

2016-03-21 23:49 GMT+01:00 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:

> Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> writes:
> > On 3/21/16 5:03 PM, Merlin Moncure wrote:
> >> in Oracle, you'd simply do:
> >> LogIt('I did something');
>
> > It would be *great* if we could support that in plpgsql.
>
> FWIW, I'm hesitant to just start accepting that syntax as if it were an
> equivalent to "SELECT f(x)" or "PERFORM f(x)". I think that someday
> we will want to have the ability to have pass-by-reference parameters
> to functions, and that's a fundamentally incompatible behavior so it
> ought to be invoked by a new syntax. I'd like to save "f(x)" as a
> bare statement for that purpose. We could also consider inventing
> "CALL f(x)"; but supposing that we already had both "CALL f(x)" (which
> would allow x to be pass-by-ref and possibly modified) and "SELECT f(x)"
> (which would not), which one would you assign bare "f(x)" to mean? It
> should be "CALL f(x)", not least because that would be the semantics most
> comparable to Oracle's behavior (since they have pass-by-ref parameters
> already).
>

I can live with SELECT fx(x). It is little bit dangerous, but this risk can
be easy detected by plpgsql_check.

>
> So, I'm -1 on not having any keyword at all. I have no objection
> to Merlin's proposal though. I agree that PERFORM is starting to
> look a bit silly, since it doesn't play with WITH for instance.
>

Isn't time to fix PERFORM instead?

>
> > While we're on the subject, it'd be great if variable := SELECT ...
> > worked too.
>
> It does, though you might need parens around the sub-select.
>
> regards, tom lane
>