Hi 2016-01-19 22:34 GMT+01:00 Jim Nasby <jim.na...@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 >
