2011/10/20 Tom Lane <tgl@sss.pgh.pa.us>:
> Pavel Stehule <pavel.stehule@gmail.com> writes:
>> I didn't design a PERFORM statement. There is two views - somebody
>> from sybase's family know so SELECT without into is forwarded to
>> client. This functionality is missing on Oracle's family. Is true so
>> PERFORM statement is strange, =C2=A0but maybe it's open door for sybase's
>> functionality that was not implemented ever.
>
> I cannot imagine that we'd ever make SELECT inside a plpgsql function
> act like that. =C2=A0Functions have no business directly transmitting
> information to the client; if they tried, they'd most likely just break
> the FE/BE protocol.
>
> There might be use for such a thing in a hypothetical "real stored
> procedure language" where the code is executing in a context entirely
> different from what Postgres functions run in ... but that language
> would be something different from plpgsql.
>
> I grant the argument that people coming from Sybase-ish DBs might be
> confused by this; but the current arrangement is also confusing lots
> of people, so I don't think that argument has all that much weight.
I agree with you you in almost all - Sybase-ish SELECT has sense for
procedures only (in PL/pgSQL) - In SQL/PSM is natural for table
functions. I disagree with Merlin or Valentine from one reason - What
is sense of SELECT, that has not processed result? Is it correct from
language design perspective?
I can do a write a query with sense - like SELECT fx(i) FROM
generate_series(1,1000) or query without sense - like SELECT 1 FROM
generate_series(1,1000) - when we enable a SELECT without INTO. And
there is next question - is first select a good idea - from
readability perspective - in PL/pgSQL - is not better to use a SQL
language??
Regards
Pavel Stehule
p.s. other question is implementation of PERFORM - that is it a just
SELECT synonym,
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0regards, tom lane
>
