Re: pl/python custom datatype parsers

Hannu Krosing <hannu@krosing.net>

From: Hannu Krosing <hannu@krosing.net>
To: Peter Eisentraut <peter_e@gmx.net>
Cc: Andrew Dunstan <andrew@dunslane.net>, Jan Urbański <wulczer@wulczer.org>, Robert Haas <robertmhaas@gmail.com>, Hitoshi Harada <umi.tanuki@gmail.com>, Postgres - Hackers <pgsql-hackers@postgresql.org>
Date: 2012-12-14T14:42:21Z
Lists: pgsql-hackers
Did any (committed?) code result from this thread ?

On 11/10/2011 09:13 PM, Peter Eisentraut wrote:
> On tis, 2011-11-08 at 16:08 -0500, Andrew Dunstan wrote:
>> On 03/01/2011 11:50 AM, Peter Eisentraut wrote:
>>> On fre, 2011-02-11 at 16:49 +0100, Jan Urbański wrote:
>>>> I believe it's (b). But as we don't have time for that discussion that
>>>> late in the release cycle, I think we need to consider it identical to (c).
>>> As I previously mentioned, I think that there should be an SQL-level way
>>> to tie together languages and types.  I previously mentioned the
>>> SQL-standard command CREATE TRANSFORM as a possibility.  I've had this
>>> on my PL/Python TOTHINK list for a while.  Thankfully you removed all
>>> the items ahead of this one, so I'll think of something to do in 9.2.
>>>
>>> Of course we'll be able to use the actual transform code that you
>>> already wrote.
>>>
>> Peter,
>>
>> Did you make any progress on this?
> No, but it's still somewhere on my list.  I saw your blog post related
> to this.
>
> I think the first step would be to set up some catalog infrastructure
> (without DDL commands and all that overhead), and try to adapt the big
> "case" statement of an existing language to that, and then check whether
> that works, performance, etc.
>
> Some other concerns of the top of my head:
>
> - Arrays: Would probably not by handled by that.  So this would not be
> able to handle, for example, switching the array handling behavior in
> PL/Perl to ancient compatible mode.
>
> - Range types: no idea
>
> I might work on this, but not before December, would be my guess.
>
>