Some of our PLs have the unfortunate problem of making a weak effort with converting types to and from the PL and Postgres. For example, plpythonu will correctly transform a complex type to a dict and an array to a list, but it punts back to text for an array contained inside a complex type. I know plTCL has similar issues; presumably other PLs are affected as well.

While it's a SMOC to fix this, what's not simple is the backwards compatability: users that are currently using these types are expecting to be handed strings created by the type's output function, so we can't just drop these changes in without breaking user code.

It might be possible to work around this with TRANSFORMs, but that's just ugly: first you'd have to write a bunch of non-trivial C code, then you'd need to forever remember to specify TRANSFORM FOR TYPE blah.

Some ways to handle this:

1) Use a PL-specific GUC for each case where we need backwards compatibility. For plpython we'd need 2. plTCL would need 1 or 2.

2) Use a single all-or-nothing GUC. Downside is that if we later decide to expand automatic conversion again we'd need yet another GUC.

3) Add the concept of PL API versions. This would allow users to specify what range of API versions they support. I think this would have been helpful with the plpython elog() patch.

4) Create a mechanism for specifying default TRANSFORMs for a PL, and essentially "solve" these issues by supplying a built-in transform.

I think default transforms (4) are worth doing no matter what. Having to manually remember to add potentially multiple TRANSFORMs is a PITA. But I'm not sure TRANSFORMS would actually fix all issues. For example, you can't specify a transform for an array type, so this probably wouldn't work for one of the plpython problems.

3 is interesting, but maybe it would be bad to tie multiple unrelated API changes together.

So I'm leaning towards 1. It means potentially adding a fair number of new GUCs, but these would all be custom GUCs, so maybe it's not that bad. The other downside to GUCs is I think it'd be nice to be able to set this at a schema level, which you can't currently do with GUCs.

Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble!

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to