From: | Joachim Wieland <joe(at)mcknight(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Matt <matt(at)kynx(dot)org>, Neil Conway <neilc(at)samurai(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: patch: plpgsql - access records with rec.(expr) |
Date: | 2004-11-24 11:14:17 |
Message-ID: | 20041124111417.GA21736@mcknight.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Nov 23, 2004 at 10:33:50AM -0500, Tom Lane wrote:
> We do need to do something about the fact that EXECUTE can't access
> plpgsql variables, though I'm afraid that fixing that is going to
> require a rather complete overhaul of plpgsql :-(. But it needs one
> anyway.
Why do you think that it would be difficult to do it with the existing code?
Actually I wanted to implement this for 8.1. I've already had a quick look
at it. My idea was to allow something like "EXECUTE SELECT INTO var1, var2
col1 col2 FROM ...". The code would have to parse the list of variables and
check if they match pl/pgsql variables, execute the query (without the INTO
stuff of course) via SPI and copy back the results, checking type mismatches
or a mismatch in the number of columns. I haven't thought about more complex
types however. Did I miss something?
Which other limitations are there in the current implementation of pl/pgsql?
Joachim
From | Date | Subject | |
---|---|---|---|
Next Message | D'Arcy J.M. Cain | 2004-11-24 11:52:30 | Re: Trouble with plpgsql on 7.4.6 |
Previous Message | Peter Eisentraut | 2004-11-24 10:29:47 | Re: -V, --version -- deprecated? |