From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: plpgsql doesn't supply typmod for the Params it generates |
Date: | 2011-05-14 02:17:13 |
Message-ID: | BANLkTikyBhn+1=iURd1S6knDNL+Tqx2kHg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, May 12, 2011 at 5:55 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2011-05-14 03:05:50 | Re: Reducing overhead of frequent table locks |
Previous Message | Robert Haas | 2011-05-14 01:52:47 | Re: Visual Studio 2010/Windows SDK 7.1 support |