Re: [HACKERS] pl/python custom datatype parsers

2012-12-14 Thread Hannu Krosing
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

Re: [HACKERS] pl/python custom datatype parsers

2011-11-10 Thread Peter Eisentraut
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

Re: [HACKERS] pl/python custom datatype parsers

2011-11-08 Thread Andrew Dunstan
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

Re: [HACKERS] pl/python custom datatype parsers

2011-03-01 Thread Peter Eisentraut
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

Re: [HACKERS] pl/python custom datatype parsers

2011-02-11 Thread Robert Haas
On Sun, Feb 6, 2011 at 1:01 PM, Jan Urbański wulc...@wulczer.org wrote: That's it for now. It is an exciting feature and plpython will be the first language to think of when you're building object database if this feature is in. The design here will affect following pl/perl and other so it is

Re: [HACKERS] pl/python custom datatype parsers

2011-02-11 Thread Jan Urbański
On 11/02/11 16:43, Robert Haas wrote: On Sun, Feb 6, 2011 at 1:01 PM, Jan Urbański wulc...@wulczer.org wrote: That's it for now. It is an exciting feature and plpython will be the first language to think of when you're building object database if this feature is in. The design here will affect

Re: [HACKERS] pl/python custom datatype parsers

2011-02-11 Thread Robert Haas
On Fri, Feb 11, 2011 at 10:49 AM, Jan Urbański wulc...@wulczer.org wrote: On 11/02/11 16:43, Robert Haas wrote: On Sun, Feb 6, 2011 at 1:01 PM, Jan Urbański wulc...@wulczer.org wrote: That's it for now. It is an exciting feature and plpython will be the first language to think of when you're

Re: [HACKERS] pl/python custom datatype parsers

2011-02-06 Thread Jan Urbański
On 04/02/11 17:19, Hitoshi Harada wrote: 2011/1/28 Jan Urbański wulc...@wulczer.org: On 23/12/10 15:15, Jan Urbański wrote: Here's a patch implementing custom parsers for data types mentioned in http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's an incremental patch on

Re: [HACKERS] pl/python custom datatype parsers

2011-02-04 Thread Hitoshi Harada
2011/1/28 Jan Urbański wulc...@wulczer.org: On 23/12/10 15:15, Jan Urbański wrote: Here's a patch implementing custom parsers for data types mentioned in http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's an incremental patch on top of the plpython-refactor patch sent

Re: [HACKERS] pl/python custom datatype parsers

2011-01-27 Thread Jan Urbański
On 23/12/10 15:15, Jan Urbański wrote: Here's a patch implementing custom parsers for data types mentioned in http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's an incremental patch on top of the plpython-refactor patch sent eariler. Updated to master. diff --git

[HACKERS] pl/python custom datatype parsers

2010-12-23 Thread Jan Urbański
Here's a patch implementing custom parsers for data types mentioned in http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's an incremental patch on top of the plpython-refactor patch sent eariler. Git branch for this patch: