Thread: 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
Hi
2016-01-19 22:34 GMT+01:00 Jim Nasby <Jim.Nasby@bluetreble.com>:
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.
the one important motivation was "don't break current code" - so TRANSFORM clause is really conservative. Please, read the mailing list related discussion. Other reasons can be performance. When you add new TRANSFORM, you don't need to recreate plans - or some similar (I don't remember it well).
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.
This topic is open and can be enhanced - but you have to be careful about performance.
Regards
Pavel
--
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:
http://www.postgresql.org/mailpref/pgsql-hackers