Re: [HACKERS] PL/Python: domain over array support

[Heikki Linnakangas]

On 11/27/13 14:15, Marko Kreen wrote:

On Tue, Nov 26, 2013 at 07:12:00PM -0200, Rodolfo Campero wrote:

2013/11/26 Heikki Linnakangas 

Oops, sorry about that. Fixed.


Maybe be you forgot to modify
plpython_types_3.out


Yes.  Heikki, please fix plpython_types_3.out too.

See attached patch.


Ah, sorry. Committed..

- Heikki


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] PL/Python: domain over array support

[Marko Kreen]

On Tue, Nov 26, 2013 at 07:12:00PM -0200, Rodolfo Campero wrote:
> 2013/11/26 Heikki Linnakangas 
> > Oops, sorry about that. Fixed.
> 
> Maybe be you forgot to modify
> plpython_types_3.out

Yes.  Heikki, please fix plpython_types_3.out too.

See attached patch.

-- 
marko

diff --git a/src/pl/plpython/expected/plpython_types_3.out b/src/pl/plpython/expected/plpython_types_3.out
index 25331f2..e104356 100644
--- a/src/pl/plpython/expected/plpython_types_3.out
+++ b/src/pl/plpython/expected/plpython_types_3.out
@@ -664,6 +664,9 @@ SELECT * FROM test_type_conversion_array_error();
 ERROR:  return value of function with array return type is not a Python sequence
 CONTEXT:  while creating return value
 PL/Python function "test_type_conversion_array_error"
+--
+-- Domains over arrays
+--
 CREATE DOMAIN ordered_pair_domain AS integer[] CHECK (array_length(VALUE,1)=2 AND VALUE[1] < VALUE[2]);
 CREATE FUNCTION test_type_conversion_array_domain(x ordered_pair_domain) RETURNS ordered_pair_domain AS $$
 plpy.info(x, type(x))

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] PL/Python: domain over array support

[Rodolfo Campero]

2013/11/26 Heikki Linnakangas 

> On 11/26/13 19:07, Kevin Grittner wrote:
>
>> Heikki Linnakangas  wrote:
>>
>>  Ok, committed.
>>>
>>
>> make check-world failure:
>>
>
> Oops, sorry about that. Fixed.


Maybe be you forgot to modify
plpython_types_3.out
?

-- 
Rodolfo

Re: [HACKERS] PL/Python: domain over array support

[Heikki Linnakangas]

On 11/26/13 19:07, Kevin Grittner wrote:

Heikki Linnakangas  wrote:


Ok, committed.


make check-world failure:


Oops, sorry about that. Fixed.

- Heikki


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] PL/Python: domain over array support

[Kevin Grittner]

Heikki Linnakangas  wrote:

> Ok, committed.

make check-world failure:

*** /home/kgrittn/pg/master/src/pl/plpython/expected/plpython_types.out 
2013-11-26 10:52:04.173441894 -0600
--- /home/kgrittn/pg/master/src/pl/plpython/results/plpython_types.out  
2013-11-26 10:55:58.229445970 -0600
***
*** 664,669 
--- 664,672 
  ERROR:  return value of function with array return type is not a Python 
sequence
  CONTEXT:  while creating return value
  PL/Python function "test_type_conversion_array_error"
+ --
+ -- Domains over arrays
+ --
  CREATE DOMAIN ordered_pair_domain AS integer[] CHECK (array_length(VALUE,1)=2 
AND VALUE[1] < VALUE[2]);
  CREATE FUNCTION test_type_conversion_array_domain(x ordered_pair_domain) 
RETURNS ordered_pair_domain AS $$
  plpy.info(x, type(x))

==

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] PL/Python: domain over array support

[Heikki Linnakangas]

On 11/26/13 11:56, Marko Kreen wrote:

On Tue, Nov 26, 2013 at 12:23:48AM +0200, Heikki Linnakangas wrote:

The new behavior is clearly better, but it is an incompatibility
nonetheless. I don't do anything with PL/python myself, so I don't
have a good feel of how much that'll break people's applications.
Probably not much I guess. But warrants a mention in the release
notes at least. Any thoughts on that?


Yes it warrants a mention but nothing excessive, in 9.0 the non-domain
arrays has same non-compatible change with only one sentence in notes.


Ok, committed. Thank you, Rodolfo and Marko!

- Heikki


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] PL/Python: domain over array support

[Marko Kreen]

On Tue, Nov 26, 2013 at 12:23:48AM +0200, Heikki Linnakangas wrote:
> The new behavior is clearly better, but it is an incompatibility
> nonetheless. I don't do anything with PL/python myself, so I don't
> have a good feel of how much that'll break people's applications.
> Probably not much I guess. But warrants a mention in the release
> notes at least. Any thoughts on that?

Yes it warrants a mention but nothing excessive, in 9.0 the non-domain
arrays has same non-compatible change with only one sentence in notes.

-- 
marko



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] PL/Python: domain over array support

[Rodolfo Campero]

2013/11/25 Heikki Linnakangas 
[...]

> This does change the behavior of any existing functions that return a
> domain over array. For example:
>
> postgres=# create domain intarr as integer[];
> CREATE DOMAIN
> postgres=# create function intarr_test() returns intarr as $$
> return '{1,2}'
> $$ language plpythonu;
> CREATE FUNCTION
>
> Before patch:
>
> postgres=# select intarr_test();
>  intarr_test
> -
>  {1,2}
> (1 row)
>
> After patch:
>
> postgres=# select intarr_test();
> ERROR:  invalid input syntax for integer: "{"
> CONTEXT:  while creating return value
> PL/Python function "intarr_test"
>
>
> The new behavior is clearly better, but it is an incompatibility
> nonetheless. I don't do anything with PL/python myself, so I don't have a
> good feel of how much that'll break people's applications. Probably not
> much I guess. But warrants a mention in the release notes at least. Any
> thoughts on that?
>
> - Heikki
>

Bear in mind that the same goes for receiving domains over arrays as
parameters; instead of seeing a string (previous behavior), with this patch
a function will see a list from the Python side (the function
implementation). A mention in the release notes is in order, I agree with
that.

I can't speak for other people, but I guess using domains over arrays as
parameters and/or return values in plpythonu functions should be rare,
considering the current behavior and especially given the possibility of
using a regular array in order to handle array values a lists in Python.

Regards,
-- 
Rodolfo

Re: [HACKERS] PL/Python: domain over array support

[Heikki Linnakangas]

On 24.11.2013 18:44, Marko Kreen wrote:

On Sat, Nov 23, 2013 at 11:09:53AM -0200, Rodolfo Campero wrote:

2013/11/22 Marko Kreen 

One more thing - please update Python 3 regtests too.


The attached patch (version 3) includes the expected results for Python 3
(file plpython_types_3.out).


Thanks.  Looks good now.


Looks good to me too.

This does change the behavior of any existing functions that return a 
domain over array. For example:


postgres=# create domain intarr as integer[];
CREATE DOMAIN
postgres=# create function intarr_test() returns intarr as $$
return '{1,2}'
$$ language plpythonu;
CREATE FUNCTION

Before patch:

postgres=# select intarr_test();
 intarr_test
-
 {1,2}
(1 row)

After patch:

postgres=# select intarr_test();
ERROR:  invalid input syntax for integer: "{"
CONTEXT:  while creating return value
PL/Python function "intarr_test"


The new behavior is clearly better, but it is an incompatibility 
nonetheless. I don't do anything with PL/python myself, so I don't have 
a good feel of how much that'll break people's applications. Probably 
not much I guess. But warrants a mention in the release notes at least. 
Any thoughts on that?


- Heikki


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] PL/Python: domain over array support

[Rodolfo Campero]

Thank you very much Marko.


2013/11/24 Marko Kreen 

> On Sat, Nov 23, 2013 at 11:09:53AM -0200, Rodolfo Campero wrote:
> > 2013/11/22 Marko Kreen 
> > > One more thing - please update Python 3 regtests too.
> > >
> > The attached patch (version 3) includes the expected results for Python 3
> > (file plpython_types_3.out).
>
> Thanks.  Looks good now.
>
> Tagging as ready for committer.
>
> --
> marko
>
>


-- 
Rodolfo Campero
Anachronics S.R.L.
Tel: (54 11) 4899 2088
rodolfo.camp...@anachronics.com
http://www.anachronics.com

Re: [HACKERS] PL/Python: domain over array support

[Marko Kreen]

On Sat, Nov 23, 2013 at 11:09:53AM -0200, Rodolfo Campero wrote:
> 2013/11/22 Marko Kreen 
> > One more thing - please update Python 3 regtests too.
> >
> The attached patch (version 3) includes the expected results for Python 3
> (file plpython_types_3.out).

Thanks.  Looks good now.

Tagging as ready for committer.

-- 
marko



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] PL/Python: domain over array support

[Rodolfo Campero]

2013/11/22 Marko Kreen 

>
> One more thing - please update Python 3 regtests too.
>
>
The attached patch (version 3) includes the expected results for Python 3
(file plpython_types_3.out).
diff --git a/src/pl/plpython/expected/plpython_types.out b/src/pl/plpython/expected/plpython_types.out
index 91106e0..785ffca 100644
--- a/src/pl/plpython/expected/plpython_types.out
+++ b/src/pl/plpython/expected/plpython_types.out
@@ -664,6 +664,34 @@ SELECT * FROM test_type_conversion_array_error();
 ERROR:  return value of function with array return type is not a Python sequence
 CONTEXT:  while creating return value
 PL/Python function "test_type_conversion_array_error"
+CREATE DOMAIN ordered_pair_domain AS integer[] CHECK (array_length(VALUE,1)=2 AND VALUE[1] < VALUE[2]);
+CREATE FUNCTION test_type_conversion_array_domain(x ordered_pair_domain) RETURNS ordered_pair_domain AS $$
+plpy.info(x, type(x))
+return x
+$$ LANGUAGE plpythonu;
+SELECT * FROM test_type_conversion_array_domain(ARRAY[0, 100]::ordered_pair_domain);
+INFO:  ([0, 100], )
+CONTEXT:  PL/Python function "test_type_conversion_array_domain"
+ test_type_conversion_array_domain 
+---
+ {0,100}
+(1 row)
+
+SELECT * FROM test_type_conversion_array_domain(NULL::ordered_pair_domain);
+INFO:  (None, )
+CONTEXT:  PL/Python function "test_type_conversion_array_domain"
+ test_type_conversion_array_domain 
+---
+ 
+(1 row)
+
+CREATE FUNCTION test_type_conversion_array_domain_check_violation() RETURNS ordered_pair_domain AS $$
+return [2,1]
+$$ LANGUAGE plpythonu;
+SELECT * FROM test_type_conversion_array_domain_check_violation();
+ERROR:  value for domain ordered_pair_domain violates check constraint "ordered_pair_domain_check"
+CONTEXT:  while creating return value
+PL/Python function "test_type_conversion_array_domain_check_violation"
 ---
 --- Composite types
 ---
diff --git a/src/pl/plpython/expected/plpython_types_3.out b/src/pl/plpython/expected/plpython_types_3.out
index 523c2ec..25331f2 100644
--- a/src/pl/plpython/expected/plpython_types_3.out
+++ b/src/pl/plpython/expected/plpython_types_3.out
@@ -664,6 +664,34 @@ SELECT * FROM test_type_conversion_array_error();
 ERROR:  return value of function with array return type is not a Python sequence
 CONTEXT:  while creating return value
 PL/Python function "test_type_conversion_array_error"
+CREATE DOMAIN ordered_pair_domain AS integer[] CHECK (array_length(VALUE,1)=2 AND VALUE[1] < VALUE[2]);
+CREATE FUNCTION test_type_conversion_array_domain(x ordered_pair_domain) RETURNS ordered_pair_domain AS $$
+plpy.info(x, type(x))
+return x
+$$ LANGUAGE plpython3u;
+SELECT * FROM test_type_conversion_array_domain(ARRAY[0, 100]::ordered_pair_domain);
+INFO:  ([0, 100], )
+CONTEXT:  PL/Python function "test_type_conversion_array_domain"
+ test_type_conversion_array_domain 
+---
+ {0,100}
+(1 row)
+
+SELECT * FROM test_type_conversion_array_domain(NULL::ordered_pair_domain);
+INFO:  (None, )
+CONTEXT:  PL/Python function "test_type_conversion_array_domain"
+ test_type_conversion_array_domain 
+---
+ 
+(1 row)
+
+CREATE FUNCTION test_type_conversion_array_domain_check_violation() RETURNS ordered_pair_domain AS $$
+return [2,1]
+$$ LANGUAGE plpython3u;
+SELECT * FROM test_type_conversion_array_domain_check_violation();
+ERROR:  value for domain ordered_pair_domain violates check constraint "ordered_pair_domain_check"
+CONTEXT:  while creating return value
+PL/Python function "test_type_conversion_array_domain_check_violation"
 ---
 --- Composite types
 ---
diff --git a/src/pl/plpython/plpy_typeio.c b/src/pl/plpython/plpy_typeio.c
index caccbf9..0a2307a 100644
--- a/src/pl/plpython/plpy_typeio.c
+++ b/src/pl/plpython/plpy_typeio.c
@@ -373,7 +373,7 @@ PLy_output_datum_func2(PLyObToDatum *arg, HeapTuple typeTup)
 	arg->typioparam = getTypeIOParam(typeTup);
 	arg->typbyval = typeStruct->typbyval;
 
-	element_type = get_element_type(arg->typoid);
+	element_type = get_base_element_type(arg->typoid);
 
 	/*
 	 * Select a conversion function to convert Python objects to PostgreSQL
@@ -427,7 +427,8 @@ static void
 PLy_input_datum_func2(PLyDatumToOb *arg, Oid typeOid, HeapTuple typeTup)
 {
 	Form_pg_type typeStruct = (Form_pg_type) GETSTRUCT(typeTup);
-	Oid			element_type = get_element_type(typeOid);
+	/* It's safe to handle domains of array types as its base array type. */
+	Oid			element_type = get_base_element_type(typeOid);
 
 	/* Get the type's conversion information */
 	perm_fmgr_info(typeStruct->typoutput, &arg->typfunc);
@@ -808,6 +809,7 @@ static Datum
 PLySequence_ToArray(PLyObToDatum *arg, int32 typmod, PyObject *plrv)
 {
 	ArrayType  *array;
+	Datum   rv;
 	int			i;
 	Datum	   *elems;
 	bool	   *nulls;
@@ -844,8 +846,15 @@ PLySequence_ToArray(PLyObToDatum *arg, int32 typmod, PyObject *plrv)
 
 	lbs = 1;
 	array = construct_md_array(elems, nulls, 1, &len, &lbs,
-			   get_element_type(

Re: [HACKERS] PL/Python: domain over array support

[Marko Kreen]

On Fri, Nov 22, 2013 at 08:45:56AM -0200, Rodolfo Campero wrote:
> There are other cosmetic changes in this patch, wrt previous version (not
> preexistent code):
>  * adjusted alignment of variable name "rv" in line 12
>  * reworded comment in line 850, resulting in more than 80 characters, so I
> splitted the comment into a multiline comment following the surrounding
> style.

Good.

One more thing - please update Python 3 regtests too.

-- 
marko



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] PL/Python: domain over array support

[Rodolfo Campero]

Marko,

2013/11/22 Marko Kreen 

> On Sat, Oct 26, 2013 at 11:17:19AM -0200, Rodolfo Campero wrote:
> > The attached patch add support of domains over arrays to PL/Python (eg:
> > CREATE DOMAIN my_domain AS integer[]).
> >
> > Basically it just uses get_base_element_type instead of get_element_type
> > in plpy_typeio.c, and uses domain_check before returning a sequence as
> > array in PLySequence_ToArray whenever appropriate.
>
> Generally looks fine.  Please lose the C++ comments though, this style
> is not used in Postgres sources.
>

Done.


> > There's one line I'm not sure about; I modified a switch statement (line
> > 427):
> > switch (element_type ? element_type : getBaseType(arg->typoid))
> > The rationale is that when element_type is set, it is already a base
> type,
> > because there is no support of arrays of domains in PostgreSQL, but this
> > may not held true in the future.
>
> Was there any actual need to modify that?  Or was it just performance
> optimization?  ATM it creates asymmetry between PLy_output_datum_func2
> and PLy_input_datum_func2.
>
> If it's just performace optimization, then it should be done in both
> functions, but seems bad idea to do it in this patch.  So I think
> it's better to leave it out.
>
>
There was no actual need to modify that, so I dropped that change in this
new patch.

There are other cosmetic changes in this patch, wrt previous version (not
preexistent code):
 * adjusted alignment of variable name "rv" in line 12
 * reworded comment in line 850, resulting in more than 80 characters, so I
splitted the comment into a multiline comment following the surrounding
style.

Thanks for your review.
diff --git a/src/pl/plpython/expected/plpython_types.out b/src/pl/plpython/expected/plpython_types.out
index 91106e0..785ffca 100644
--- a/src/pl/plpython/expected/plpython_types.out
+++ b/src/pl/plpython/expected/plpython_types.out
@@ -664,6 +664,34 @@ SELECT * FROM test_type_conversion_array_error();
 ERROR:  return value of function with array return type is not a Python sequence
 CONTEXT:  while creating return value
 PL/Python function "test_type_conversion_array_error"
+CREATE DOMAIN ordered_pair_domain AS integer[] CHECK (array_length(VALUE,1)=2 AND VALUE[1] < VALUE[2]);
+CREATE FUNCTION test_type_conversion_array_domain(x ordered_pair_domain) RETURNS ordered_pair_domain AS $$
+plpy.info(x, type(x))
+return x
+$$ LANGUAGE plpythonu;
+SELECT * FROM test_type_conversion_array_domain(ARRAY[0, 100]::ordered_pair_domain);
+INFO:  ([0, 100], )
+CONTEXT:  PL/Python function "test_type_conversion_array_domain"
+ test_type_conversion_array_domain 
+---
+ {0,100}
+(1 row)
+
+SELECT * FROM test_type_conversion_array_domain(NULL::ordered_pair_domain);
+INFO:  (None, )
+CONTEXT:  PL/Python function "test_type_conversion_array_domain"
+ test_type_conversion_array_domain 
+---
+ 
+(1 row)
+
+CREATE FUNCTION test_type_conversion_array_domain_check_violation() RETURNS ordered_pair_domain AS $$
+return [2,1]
+$$ LANGUAGE plpythonu;
+SELECT * FROM test_type_conversion_array_domain_check_violation();
+ERROR:  value for domain ordered_pair_domain violates check constraint "ordered_pair_domain_check"
+CONTEXT:  while creating return value
+PL/Python function "test_type_conversion_array_domain_check_violation"
 ---
 --- Composite types
 ---
diff --git a/src/pl/plpython/plpy_typeio.c b/src/pl/plpython/plpy_typeio.c
index caccbf9..0a2307a 100644
--- a/src/pl/plpython/plpy_typeio.c
+++ b/src/pl/plpython/plpy_typeio.c
@@ -373,7 +373,7 @@ PLy_output_datum_func2(PLyObToDatum *arg, HeapTuple typeTup)
 	arg->typioparam = getTypeIOParam(typeTup);
 	arg->typbyval = typeStruct->typbyval;
 
-	element_type = get_element_type(arg->typoid);
+	element_type = get_base_element_type(arg->typoid);
 
 	/*
 	 * Select a conversion function to convert Python objects to PostgreSQL
@@ -427,7 +427,8 @@ static void
 PLy_input_datum_func2(PLyDatumToOb *arg, Oid typeOid, HeapTuple typeTup)
 {
 	Form_pg_type typeStruct = (Form_pg_type) GETSTRUCT(typeTup);
-	Oid			element_type = get_element_type(typeOid);
+	/* It's safe to handle domains of array types as its base array type. */
+	Oid			element_type = get_base_element_type(typeOid);
 
 	/* Get the type's conversion information */
 	perm_fmgr_info(typeStruct->typoutput, &arg->typfunc);
@@ -808,6 +809,7 @@ static Datum
 PLySequence_ToArray(PLyObToDatum *arg, int32 typmod, PyObject *plrv)
 {
 	ArrayType  *array;
+	Datum   rv;
 	int			i;
 	Datum	   *elems;
 	bool	   *nulls;
@@ -844,8 +846,15 @@ PLySequence_ToArray(PLyObToDatum *arg, int32 typmod, PyObject *plrv)
 
 	lbs = 1;
 	array = construct_md_array(elems, nulls, 1, &len, &lbs,
-			   get_element_type(arg->typoid), arg->elm->typlen, arg->elm->typbyval, arg->elm->typalign);
-	return PointerGetDatum(array);
+			   get_base_element_type(arg->typoid), arg->elm->typlen, arg->elm->typbyval, arg->elm->typalign);
+	/*
+	 * If the result type is a 

Re: [HACKERS] PL/Python: domain over array support

[Marko Kreen]

On Sat, Oct 26, 2013 at 11:17:19AM -0200, Rodolfo Campero wrote:
> The attached patch add support of domains over arrays to PL/Python (eg:
> CREATE DOMAIN my_domain AS integer[]).
> 
> Basically it just uses get_base_element_type instead of get_element_type
> in plpy_typeio.c, and uses domain_check before returning a sequence as
> array in PLySequence_ToArray whenever appropriate.

Generally looks fine.  Please lose the C++ comments though, this style
is not used in Postgres sources.

> There's one line I'm not sure about; I modified a switch statement (line
> 427):
> switch (element_type ? element_type : getBaseType(arg->typoid))
> The rationale is that when element_type is set, it is already a base type,
> because there is no support of arrays of domains in PostgreSQL, but this
> may not held true in the future.

Was there any actual need to modify that?  Or was it just performance
optimization?  ATM it creates asymmetry between PLy_output_datum_func2
and PLy_input_datum_func2.

If it's just performace optimization, then it should be done in both
functions, but seems bad idea to do it in this patch.  So I think
it's better to leave it out.

-- 
marko



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] PL/Python: domain over array support

[Rodolfo Campero]

Done, thanks.


2013/10/28 Robert Haas 

> On Sat, Oct 26, 2013 at 9:17 AM, Rodolfo Campero
>  wrote:
> > The attached patch add support of domains over arrays to PL/Python (eg:
> > CREATE DOMAIN my_domain AS integer[]).
> >
> > Basically it just uses get_base_element_type instead of get_element_type
> in
> > plpy_typeio.c, and uses domain_check before returning a sequence as
> array in
> > PLySequence_ToArray whenever appropriate.
> >
> > There's one line I'm not sure about; I modified a switch statement (line
> > 427):
> > switch (element_type ? element_type : getBaseType(arg->typoid))
> > The rationale is that when element_type is set, it is already a base
> type,
> > because there is no support of arrays of domains in PostgreSQL, but this
> may
> > not held true in the future.
>
> Please add your patch here so that it doesn't get forgotten about:
>
> https://commitfest.postgresql.org/action/commitfest_view/open
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

Re: [HACKERS] PL/Python: domain over array support

[Robert Haas]

On Sat, Oct 26, 2013 at 9:17 AM, Rodolfo Campero
 wrote:
> The attached patch add support of domains over arrays to PL/Python (eg:
> CREATE DOMAIN my_domain AS integer[]).
>
> Basically it just uses get_base_element_type instead of get_element_type in
> plpy_typeio.c, and uses domain_check before returning a sequence as array in
> PLySequence_ToArray whenever appropriate.
>
> There's one line I'm not sure about; I modified a switch statement (line
> 427):
> switch (element_type ? element_type : getBaseType(arg->typoid))
> The rationale is that when element_type is set, it is already a base type,
> because there is no support of arrays of domains in PostgreSQL, but this may
> not held true in the future.

Please add your patch here so that it doesn't get forgotten about:

https://commitfest.postgresql.org/action/commitfest_view/open

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] PL/Python: domain over array support

[Rodolfo Campero]

The attached patch add support of domains over arrays to PL/Python (eg:
CREATE DOMAIN my_domain AS integer[]).

Basically it just uses get_base_element_type instead of get_element_type
in plpy_typeio.c, and uses domain_check before returning a sequence as
array in PLySequence_ToArray whenever appropriate.

There's one line I'm not sure about; I modified a switch statement (line
427):
switch (element_type ? element_type : getBaseType(arg->typoid))
The rationale is that when element_type is set, it is already a base type,
because there is no support of arrays of domains in PostgreSQL, but this
may not held true in the future.

Regards,
Rodolfo


plpython_domain_over_array_v1.patch
Description: Binary data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers