Handling changes to default type transformations in PLs

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.

Thoughts?
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com