Re: plpgsql doesn't supply typmod for the Params it generates - Mailing list pgsql-hackers

From Robert Haas
Subject Re: plpgsql doesn't supply typmod for the Params it generates
Date
Msg-id BANLkTikyBhn+1=iURd1S6knDNL+Tqx2kHg@mail.gmail.com
Whole thread Raw
In response to Re: plpgsql doesn't supply typmod for the Params it generates  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, May 12, 2011 at 5:55 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wrote:
>> I think the appropriate fix is pretty clear: add a function similar to
>> exec_get_datum_type that returns the datum's typmod, and use that to set
>> paramtypmod properly.  What is worrying me is that it's not clear how
>> much user-visible behavioral change will result, and therefore I'm not
>> entirely comfortable with the idea of back-patching such a change into
>> 9.0 --- and it wouldn't work at all in 8.4, where there simply isn't a
>> good opportunity to set a typmod for parameters passed to the main
>> executor (since the SPI interfaces plpgsql uses don't support that).
>
> Attached is a proposed patch for HEAD that sets up the Param's typmod
> sanely.  I've verified that this fixes the reported problem and does not
> result in any changes in the regression tests, which makes me a bit more
> optimistic about it ... but I'm still not convinced it'd be a good idea
> to back-patch into 9.0.

Back-patching doesn't seem very safe to me, either; though I'm not
entirely certain what to do instead.  Relaxing the check, as you
proposed upthread, might be the way to go.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Visual Studio 2010/Windows SDK 7.1 support
Next
From: Noah Misch
Date:
Subject: Re: Reducing overhead of frequent table locks