Rethinking TRANSFORM FOR TYPE ...

I'm using the TRANSFORM feature to implement a new data type for python
(ndarrays from numpy). I'm constantly getting tripped up by forgetting
to add TRANSFORM FOR TYPE. Worse, the requirement for explicitly stating
transform means I can't use a polymorphic type.

In the case of adding a new transform for an existing type, current
behavior makes sense; you'll break all existing functions using the type
if you just swap the representation out under them. Further, if you are
pulling in some new extension that uses the same language and type, that
function will be expecting the old representation, not the new one.

For the case of creating a new data type, I think explicitly requiring
the TRANSFORM clause makes no sense. It's a bunch of extra work for
users that adds no benefit.

A simple way to fix this would be to allow simply marking a transform as
being DEFAULT. If a transform is marked as DEFAULT then it would
automatically get used.

Perhaps a better way would be allowing for multiple transforms for each
language and type. That way users aren't stuck with a single
preconceived notion of how to represent a type. The immediate use I see
for that is it would allow a transform to be created in something other
than C, as long as the language you want to use can handle a raw C
string. That desire might sound silly to a lot of -hackers, but given
the amount of pain I went through figuring out how to properly marshal
an ndarray back and forth in C, I sure as hell wish I could have done it
in python! Since plpythonu understands bytea, I don't see any reason I
couldn't have.
--
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