Re: plpgsql doesn't supply typmod for the Params it generates
От | Robert Haas |
---|---|
Тема | Re: plpgsql doesn't supply typmod for the Params it generates |
Дата | |
Msg-id | BANLkTikyBhn+1=iURd1S6knDNL+Tqx2kHg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: plpgsql doesn't supply typmod for the Params it generates (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: