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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to