Re: [HACKERS] Handling changes to default type transformations in PLs

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

Re: [HACKERS] Handling changes to default type transformations in PLs

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

Re: [HACKERS] Handling changes to default type transformations in PLs

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

[HACKERS] Handling changes to default type transformations in PLs

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