Lists: | pgsql-patches |
---|
From: | Pavel Stehule <stehule(at)kix(dot)fsv(dot)cvut(dot)cz> |
---|---|
To: | pgsql-patches(at)postgresql(dot)org |
Subject: | patch for EXECUTE .. INTO (from TODO) |
Date: | 2005-06-01 09:30:38 |
Message-ID: | Pine.LNX.4.44.0506011125210.27735-200000@kix.fsv.cvut.cz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-patches |
Hello
I did small trivial patch (almost all was written) for storing
result from executing dynamic query into ROW or RECORD variable.
CREATE TABLE fxx(i integer, y integer);
CREATE TYPE fxt AS (i integer, z integer);
CREATE OR REPLACE FUNCTION foo(varchar) RETURNS RECORD AS $$
DECLARE _r RECORD; _f fxx%ROWTYPE; _t fxt; z fxx;
BEGIN
DELETE FROM fxx;
EXECUTE 'INSERT INTO fxx VALUES(10,15)';
EXECUTE 'SELECT (row).* from (select row(10,1)::fxx)s' INTO _r;
RAISE NOTICE '%', _r.i;
EXECUTE 'SELECT * FROM '||$1||' LIMIT 1' INTO _f;
RETURN _f;
END; $$ LANGUAGE plpgsql;
SELECT foo('fxx');
pokus=# NOTICE: 10
foo
---------
(10,15)
(1 row)
Best regards
Pavel Stehule
Attachment | Content-Type | Size |
---|---|---|
executeinto.diff | text/plain | 5.8 KB |
From: | Neil Conway <neilc(at)samurai(dot)com> |
---|---|
To: | Pavel Stehule <stehule(at)kix(dot)fsv(dot)cvut(dot)cz> |
Cc: | pgsql-patches(at)postgresql(dot)org |
Subject: | Re: patch for EXECUTE .. INTO (from TODO) |
Date: | 2005-06-02 07:56:11 |
Message-ID: | 1117698971.2605.33.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-patches |
On Wed, 2005-06-01 at 11:30 +0200, Pavel Stehule wrote:
> I did small trivial patch (almost all was written) for storing
> result from executing dynamic query into ROW or RECORD variable.
Cool, this will be useful. A few minor comments:
The patch needs some regression tests.
I'm not sure the parser modifications are quite right -- these
statements are treated as identical:
EXECUTE 'SELECT (row).* from (select row(10,1)::fxx) s'; _r;
EXECUTE 'SELECT (row).* from (select row(10,1)::fxx) s' INTO _r;
Accepting the former as valid syntax might mean misinterpreting some
function definitions (for example, EXECUTE '...'; var := 5). If you use
read_sql_construct() directly, you can use the *endtoken out parameter
to check whether the parser saw an INTO or a semicolon, and only look
for a following variable in the former case. In any case there's not
much point in defining plpgsql_read_expression2(), the rest of gram.y
just uses read_sql_construct() directly.
-Neil