2011/10/20 Tom Lane <t...@sss.pgh.pa.us>: > Pavel Stehule <pavel.steh...@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, but 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. Functions 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, > > regards, tom lane > -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
