Re: pl/python custom datatype parsers
От | Hannu Krosing |
---|---|
Тема | Re: pl/python custom datatype parsers |
Дата | |
Msg-id | 50CB3ACD.2060504@krosing.net обсуждение исходный текст |
Ответ на | Re: pl/python custom datatype parsers (Peter Eisentraut <peter_e@gmx.net>) |
Список | 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. > >
В списке pgsql-hackers по дате отправления: