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 s
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 statements called from PLs.
Added.
--
Bruce Momjian [EMAIL PROTECTED]
Enterprise
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: Hav
OK, what is the TODO wording?
---
Andrew Dunstan wrote:
> 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
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
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 along
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 acces
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: src/pl/plperl/plpe
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 re
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
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 limi
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
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 vers
13 matches
Mail list logo