| From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> | 
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
| Cc: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: Relax requirement for INTO with SELECT in pl/pgsql | 
| Date: | 2016-03-22 05:20:01 | 
| Message-ID: | CAFj8pRDFkx1Fq=xmmCwB6Djc=z5tzNdPgur-g1MqEwG7fbtZGw@mail.gmail.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
2016-03-22 6:06 GMT+01:00 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> > I can live with SELECT fx(x). It is little bit dangerous, but this risk
> can
> > be easy detected by plpgsql_check.
>
> Dangerous how?
>
I afraid of useless and forgotten call of functions. But the risk is same
like PERFORM - so this is valid from one half. The PERFORM statement holds
special semantic, and it is interesting.
But I don't see any risk if we allow SELECT fx(x) without INTO when fx is
void function. It is absolutely correct.
>
> >> 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?
>
> I do not think it can be fixed without embedding knowledge of PERFORM into
> the core parser, which I doubt anybody would consider a good idea.
>
I don't see, why PERFORM should be in core parser? What use case should be
fixed?
Regards
Pavel
>
>                         regards, tom lane
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2016-03-22 05:28:46 | Re: parallel aggregation - Numeric is unsupported? | 
| Previous Message | Amit Kapila | 2016-03-22 05:19:29 | Re: OOM in libpq and infinite loop with getCopyStart() |