Horton

Re: plpgsql doesn't supply typmod for the Params it generates

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Date: 2011-05-14T02:17:13Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix plpgsql's issues with dropped columns in rowtypes in 8.4 branch.

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