PL/Python: domain over array support
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
Attachments:
plpython_domain_over_array_v1.patchapplication/octet-stream; name=plpython_domain_over_array_v1.patchDownload
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], <type 'list'>)
+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, <type 'NoneType'>)
+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..826af1f 100644
--- a/src/pl/plpython/plpy_typeio.c
+++ b/src/pl/plpython/plpy_typeio.c
@@ -373,13 +373,14 @@ 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
* datums. Most data types can go through the generic function.
*/
- switch (getBaseType(element_type ? element_type : arg->typoid))
+ /* if element_type is set, it is already a base type */
+ switch (element_type ? element_type : getBaseType(arg->typoid))
{
case BOOLOID:
arg->func = PLyObject_ToBool;
@@ -427,7 +428,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 +810,7 @@ static Datum
PLySequence_ToArray(PLyObToDatum *arg, int32 typmod, PyObject *plrv)
{
ArrayType *array;
+ Datum rv;
int i;
Datum *elems;
bool *nulls;
@@ -844,8 +847,12 @@ 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 domain of array, we must check it
+ rv = PointerGetDatum(array);
+ if (get_typtype(arg->typoid) == TYPTYPE_DOMAIN)
+ domain_check(rv, false, arg->typoid, &arg->typfunc.fn_extra, arg->typfunc.fn_mcxt);
+ return rv;
}
diff --git a/src/pl/plpython/sql/plpython_types.sql b/src/pl/plpython/sql/plpython_types.sql
index e63d07e..dc1d15a 100644
--- a/src/pl/plpython/sql/plpython_types.sql
+++ b/src/pl/plpython/sql/plpython_types.sql
@@ -293,6 +293,22 @@ $$ LANGUAGE plpythonu;
SELECT * FROM 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);
+SELECT * FROM test_type_conversion_array_domain(NULL::ordered_pair_domain);
+
+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();
+
+
---
--- Composite types
On Sat, Oct 26, 2013 at 9:17 AM, Rodolfo Campero
<rodolfo.campero@anachronics.com> 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
Done, thanks.
2013/10/28 Robert Haas <robertmhaas@gmail.com>
Show quoted text
On Sat, Oct 26, 2013 at 9:17 AM, Rodolfo Campero
<rodolfo.campero@anachronics.com> 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 basetype,
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
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
Marko,
2013/11/22 Marko Kreen <markokr@gmail.com>
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 basetype,
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.
Attachments:
plpython_domain_over_array_v2.patchtext/x-patch; charset=US-ASCII; name=plpython_domain_over_array_v2.patchDownload
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], <type 'list'>)
+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, <type 'NoneType'>)
+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 domain of array, the resulting array must be
+ * checked.
+ */
+ rv = PointerGetDatum(array);
+ if (get_typtype(arg->typoid) == TYPTYPE_DOMAIN)
+ domain_check(rv, false, arg->typoid, &arg->typfunc.fn_extra, arg->typfunc.fn_mcxt);
+ return rv;
}
diff --git a/src/pl/plpython/sql/plpython_types.sql b/src/pl/plpython/sql/plpython_types.sql
index e63d07e..dc1d15a 100644
--- a/src/pl/plpython/sql/plpython_types.sql
+++ b/src/pl/plpython/sql/plpython_types.sql
@@ -293,6 +293,22 @@ $$ LANGUAGE plpythonu;
SELECT * FROM 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);
+SELECT * FROM test_type_conversion_array_domain(NULL::ordered_pair_domain);
+
+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();
+
+
---
--- Composite types
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
2013/11/22 Marko Kreen <markokr@gmail.com>
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).
Attachments:
plpython_domain_over_array_v3.patchtext/x-patch; charset=US-ASCII; name=plpython_domain_over_array_v3.patchDownload
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], <type 'list'>)
+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, <type 'NoneType'>)
+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], <class 'list'>)
+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, <class 'NoneType'>)
+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(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 domain of array, the resulting array must be
+ * checked.
+ */
+ rv = PointerGetDatum(array);
+ if (get_typtype(arg->typoid) == TYPTYPE_DOMAIN)
+ domain_check(rv, false, arg->typoid, &arg->typfunc.fn_extra, arg->typfunc.fn_mcxt);
+ return rv;
}
diff --git a/src/pl/plpython/sql/plpython_types.sql b/src/pl/plpython/sql/plpython_types.sql
index e63d07e..dc1d15a 100644
--- a/src/pl/plpython/sql/plpython_types.sql
+++ b/src/pl/plpython/sql/plpython_types.sql
@@ -293,6 +293,22 @@ $$ LANGUAGE plpythonu;
SELECT * FROM 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);
+SELECT * FROM test_type_conversion_array_domain(NULL::ordered_pair_domain);
+
+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();
+
+
---
--- Composite types
On Sat, Nov 23, 2013 at 11:09:53AM -0200, Rodolfo Campero wrote:
2013/11/22 Marko Kreen <markokr@gmail.com>
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
Thank you very much Marko.
2013/11/24 Marko Kreen <markokr@gmail.com>
On Sat, Nov 23, 2013 at 11:09:53AM -0200, Rodolfo Campero wrote:
2013/11/22 Marko Kreen <markokr@gmail.com>
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.campero@anachronics.com
http://www.anachronics.com
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 <markokr@gmail.com>
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
2013/11/25 Heikki Linnakangas <hlinnakangas@vmware.com>
[...]
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 FUNCTIONBefore 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
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
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
Heikki Linnakangas <hlinnakangas@vmware.com> 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
On 11/26/13 19:07, Kevin Grittner wrote:
Heikki Linnakangas <hlinnakangas@vmware.com> 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
2013/11/26 Heikki Linnakangas <hlinnakangas@vmware.com>
On 11/26/13 19:07, Kevin Grittner wrote:
Heikki Linnakangas <hlinnakangas@vmware.com> wrote:
Ok, committed.
make check-world failure:
Oops, sorry about that. Fixed.
Maybe be you forgot to modify
plpython_types_3.out<http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/pl/plpython/expected/plpython_types_3.out;h=25331f268a1e456a484ccba328198eed2cd87313;hb=37364c63115a52b4dc7ea280aa5b358abd4a9c38>
?
--
Rodolfo
On Tue, Nov 26, 2013 at 07:12:00PM -0200, Rodolfo Campero wrote:
2013/11/26 Heikki Linnakangas <hlinnakangas@vmware.com>
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
Attachments:
plpy.comment.difftext/x-diff; charset=us-asciiDownload
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))
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 <hlinnakangas@vmware.com>
Oops, sorry about that. Fixed.
Maybe be you forgot to modify
plpython_types_3.outYes. 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