Re: PL/pgSQL PERFORM with CTE - Mailing list pgsql-hackers

From Tom Lane
Subject Re: PL/pgSQL PERFORM with CTE
Date
Msg-id 22183.1377635354@sss.pgh.pa.us
Whole thread Raw
In response to Re: PL/pgSQL PERFORM with CTE  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: PL/pgSQL PERFORM with CTE  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
Pavel Stehule <pavel.stehule@gmail.com> writes:
> 2013/8/27 David E. Wheeler <david@justatheory.com>
>> But whatever the keyword, I think it makes sense to require one to return
>> results to the caller. Any query that does not return, yield, or capture
>> (select into) values should just have its results discarded.

> A usual and first solution and syntax is defined by Sybase - we can define
> own syntax, but I don't think so it is necessary be original everywhere.
> My opinion is surely subjective - this feature is one from few features
> that are nice on T-SQL.

We aren't following T-SQL on any other syntax detail, so why would we
start with this one?  plpgsql is meant to follow Oracle syntax not T-SQL.

I agree with David that we should use some new syntax to specify
return-results-directly-to-client, assuming we ever get any such
functionality.  It seems like a pretty bad choice of default behavior,
which is essentially what you're saying it should be.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_restore multiple --function options
Next
From: David Fetter
Date:
Subject: Re: pg_restore multiple --function options