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

> 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



> --
> 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

Reply via email to