2007/5/3, Tom Lane [EMAIL PROTECTED]:
Neil Conway [EMAIL PROTECTED] writes:
Pavel, my apologies for not getting back to you sooner.
On Wed, 2007-25-04 at 07:12 +0200, Pavel Stehule wrote:
example: I have table with attr. cust_id, and I want to use parametrized
view (table function) where I
On 4/25/07, Pavel Stehule [EMAIL PROTECTED] wrote:
for me RETURNS TABLE (a,b) isn't equialent for (OUT a, OUT b) RETURNS SETOF
RECORD, but
it's eq. for RETURNS SETOF RECORD ... and SELECT FROM foo() AS (a, b).
Reason:
example: I have table with attr. cust_id, and I want to use parametrized
Tom, Pavel,
Hmm, I see your point. I'm personally satisfied with adding a new
proargmode to solve this as you suggest.
This will break client-side code that looks at proargmode, and I don't
think the argument in favor is strong enough to justify that ...
What kind of client-side code are
Josh Berkus wrote:
Tom, Pavel,
Hmm, I see your point. I'm personally satisfied with adding a new
proargmode to solve this as you suggest.
This will break client-side code that looks at proargmode, and I don't
think the argument in favor is strong enough to justify that ...
What kind of
Pavel, my apologies for not getting back to you sooner.
On Wed, 2007-25-04 at 07:12 +0200, Pavel Stehule wrote:
example: I have table with attr. cust_id, and I want to use parametrized
view (table function) where I want to have attr cust_id on output.
Hmm, I see your point. I'm personally
Neil Conway [EMAIL PROTECTED] writes:
Pavel, my apologies for not getting back to you sooner.
On Wed, 2007-25-04 at 07:12 +0200, Pavel Stehule wrote:
example: I have table with attr. cust_id, and I want to use parametrized
view (table function) where I want to have attr cust_id on output.
On Mon, 2007-04-23 at 17:48 -0400, Tom Lane wrote:
I think we've got something isomorphic to that in the patch queue
already --- take a look at Pavel's table function patch. It's in
need of cleanup but I think it will make it in.
Interesting -- I missed that patch, but it seems like a better
Hello
It is RETURN TABLE(SQL) via ANSI SQL 2003
Table function support is in patch queue:
http://archives.postgresql.org/pgsql-patches/2007-02/msg00216.php
http://momjian.us/mhonarc/patches/msg1.html
Regards
Pavel Stehule
In a PL/PgSQL set-returning function, returning the result set
Neil Conway [EMAIL PROTECTED] writes:
Interesting -- I missed that patch, but it seems like a better approach.
Are you already reviewing Pavel's patch, or is it something I could take
a look at?
The main objection I have is that I don't think changing the definition
of pg_proc.proargmodes is a
On Tue, 2007-04-24 at 07:58 +0200, Pavel Stehule wrote:
It is RETURN TABLE(SQL) via ANSI SQL 2003
I think there are two basically orthogonal features in the patch: the
RETURNS TABLE addition to CREATE FUNCTION, and the RETURN TABLE
statement in PL/PgSQL. The former is specified by the SQL
I think there are two basically orthogonal features in the patch: the
RETURNS TABLE addition to CREATE FUNCTION, and the RETURN TABLE
statement in PL/PgSQL. The former is specified by the SQL standard and
is applicable to all PLs, while the latter is syntax sugar for PL/PgSQL.
I think it would
Neil,
This works, but it seems overly verbose. It occurred to me that we could
easily add a new PL/PgSQL statement that evaluates a set-returning
expression and adds *all* the resulting rows to the function's result
set. For example:
RETURN QUERY SELECT ...;
I'm not sure of the right
Neil Conway [EMAIL PROTECTED] writes:
This works, but it seems overly verbose. It occurred to me that we could
easily add a new PL/PgSQL statement that evaluates a set-returning
expression and adds *all* the resulting rows to the function's result
set. For example:
I think we've got something
Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
This works, but it seems overly verbose. It occurred to me that we could
easily add a new PL/PgSQL statement that evaluates a set-returning
expression and adds *all* the resulting rows to the function's result
set. For example:
I
14 matches
Mail list logo
