> 4) Create a mechanism for specifying default TRANSFORMs for a PL, and
> essentially "solve" these issues by supplying a built-in transform.
>
> I think default transforms (4) are worth doing no matter what. Having to
> manually remember to add potentially multiple TRANSFORMs is a PITA. But I'm
>
> > 3) Add the concept of PL API versions. This would allow users to specify
>
> So that leaves #3, which doesn't seem all that unreasonable from here.
> We don't have a problem with bundling a bunch of unrelated changes
> into any one major PG revision. The scripting languages we're talking
> abo
Jim Nasby writes:
> Some of our PLs have the unfortunate problem of making a weak effort
> with converting types to and from the PL and Postgres. For example,
> plpythonu will correctly transform a complex type to a dict and an array
> to a list, but it punts back to text for an array contained
Some of our PLs have the unfortunate problem of making a weak effort
with converting types to and from the PL and Postgres. For example,
plpythonu will correctly transform a complex type to a dict and an array
to a list, but it punts back to text for an array contained inside a
complex type. I