What about plpgsql variables, ie:
DECLARE
v varchar(42);
BEGIN
...
On Jan 26, 2007, at 9:48 PM, Andrew Dunstan wrote:
Bruce Momjian wrote:
OK, what is the TODO wording?cheers
Something like:
Enforce typmod for function inputs, function results and parameters
for spi_prepare'd
I wrote:
Tom Lane wrote:
I think parseTypeString() may be the thing to use. It's what plpgsql
uses...
OK, I'll see what I can do.
see attached patch. If this is OK I will apply it and also fix pltcl
and plpython similarly, mutatis mutandis.
cheers
andrew
Index:
Andrew Dunstan [EMAIL PROTECTED] writes:
see attached patch. If this is OK I will apply it and also fix pltcl
and plpython similarly, mutatis mutandis.
Looks alright as far as it goes, but I'd suggest making one additional
cleanup while you're in there: get rid of the direct syscache access
On Jan 26, 2007, at 9:31 AM, Tom Lane wrote:
If you wanted to be a bit more ambitious maybe you could change the
fact
that this code is throwing away typmod, which means that declarations
like varchar(32) would fail to work as expected. Perhaps it
should be
fixed to save the typmods
Jim Nasby wrote:
On Jan 26, 2007, at 9:31 AM, Tom Lane wrote:
If you wanted to be a bit more ambitious maybe you could change the fact
that this code is throwing away typmod, which means that declarations
like varchar(32) would fail to work as expected. Perhaps it should be
fixed to save the
Bruce Momjian wrote:
OK, what is the TODO wording?cheers
Something like:
Enforce typmod for function inputs, function results and parameters for
spi_prepare'd statements called from PLs.
cheers
andrew
---(end of broadcast)---
TIP 3:
The author of this bug was good enough to send me a copy, since I don't
normally read the -bugs list. It can now be found at
http://archives.postgresql.org/pgsql-bugs/2007-01/msg00111.php .
I dug into it a bit and found that pltcl and plpython appear to use
almost identical code, but only
I wrote:
I see that SQL level prepare calls regprocin() to resolve type names,
so maybe we should that for the PLs when calling SPI_prepare as well.
Of course, that should be regtypein()
cheers
andrew
---(end of broadcast)---
TIP 9: In
Andrew Dunstan [EMAIL PROTECTED] writes:
I see that SQL level prepare calls regprocin() to resolve type names,
so maybe we should that for the PLs when calling SPI_prepare as well.
Of course, that should be regtypein()
[ squint... ] build_regtype_array seems a rather stupid bit of code.
How
Andrew Dunstan [EMAIL PROTECTED] writes:
I dug into it a bit and found that pltcl and plpython appear to use
almost identical code, but only pltcl has this limitation documented.
I'm inclined to say we should document this for plperl and plpython for
stable releases and remove the
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I see that SQL level prepare calls regprocin() to resolve type names,
so maybe we should that for the PLs when calling SPI_prepare as well.
Of course, that should be regtypein()
[ squint... ] build_regtype_array seems a
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I dug into it a bit and found that pltcl and plpython appear to use
almost identical code, but only pltcl has this limitation documented.
I'm inclined to say we should document this for plperl and plpython for
stable releases and
12 matches
Mail list logo
