Re: Rethinking TRANSFORM FOR TYPE ...

Hi

2016-01-19 22:34 GMT+01:00 Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>