Re: [HACKERS] Duda

[Rodolfo Campero]

La lista de correo apropiada para tu consulta es pgsql-es-ayuda
(pgsql-es-ayuda(at)postgresql(dot)org).
Saludos,

El 13 de octubre de 2015, 16:51, Enrique Escobar <eku...@live.com.mx>
escribió:

> Hola
> Tengo una duda, que tan pesado es poner ssl en una base. (me refiero si es
> mas pesado para el equipo usar esta conexión o es igual a una con ip en hba?
> Mil Gracias
>
>
> --
> Saludos Enrique
>

-- 
Rodolfo Campero

Re: [HACKERS] PL/pgSQL 2

[Rodolfo Campero]

2014-09-04 18:29 GMT-03:00 Robert Haas robertmh...@gmail.com:

 On Thu, Sep 4, 2014 at 2:31 PM, Josh Berkus j...@agliodbs.com wrote:
  Sadly, what's prevented us from having packages already has been the
  insistence of potential feature sponsors that they work *exactly* like
  PL/SQL's packages, which is incompatible with Postgres namespacing.
  Also, we'd want any package concept to be usable with external PLs as
  well as PL/pgSQL, which necessitates other Oracle-incompatible changes.

 This is not a fun area in which to try to be exactly like Oracle.
 Just to take one example, the whole package is created and dumped as a
 single object, with all of its contained functions *and their
 comments*, including the exact position of those comments, such as
 inside the argument list to document what particular arguments are
 supposed to do.  We've worked out a (partial) solution to that problem
 in Advanced Server, but it's not perfect, and it limits the ability to
 implement other features that PostgreSQL users would probably expect,
 like being able to add a function to a package after-the-fact.
 PostgreSQL has a certain cleanliness of design that comes from doing
 things in a way that makes sense from first principles, rather than
 the way that other people may have done it.  I'm not prepared to say
 that a $184B company made a bad design decision here - it certainly
 seems to have worked out for them - but it's not what I would have
 picked, and it's not a very good fit for other design decisions we've
 made in PostgreSQL already.

 All-in-all, I'm pretty happy with our EXTENSION system as a way of
 loading code (and SQL function definitions) in a modular way.  It's
 not perfect, but it's definitely made my life as a developer easier.
 There are some things you can do with an Oracle package but not a
 PostgreSQL extension, but there is an awful lot of overlap, too.  I
 doubt we'd want to duplicate all that machinery just for compatibility
 reasons.


If it were possible to mark a function as private for its extension that
would be awesome (the opposite would work too, i.e. a way to specify a
public API, meaning the rest is private). For big extensions it's not clear
which functions can be used directly by users of the extension and which
ones are just implementation details.

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

[Rodolfo Campero]

2013/11/26 Heikki Linnakangas hlinnakan...@vmware.com

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

 Heikki Linnakangas hlinnakan...@vmware.com wrote:

  Ok, committed.


 make check-world failure:


 Oops, sorry about that. Fixed.


Maybe be you forgot to modify
plpython_types_3.outhttp://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/pl/plpython/expected/plpython_types_3.out;h=25331f268a1e456a484ccba328198eed2cd87313;hb=37364c63115a52b4dc7ea280aa5b358abd4a9c38
?

-- 
Rodolfo

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

[Rodolfo Campero]

2013/11/25 Heikki Linnakangas hlinnakan...@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 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

[Rodolfo Campero]

Thank you very much Marko.


2013/11/24 Marko Kreen mark...@gmail.com

 On Sat, Nov 23, 2013 at 11:09:53AM -0200, Rodolfo Campero wrote:
  2013/11/22 Marko Kreen mark...@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.camp...@anachronics.com
http://www.anachronics.com

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

[Rodolfo Campero]

2013/11/22 Marko Kreen mark...@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).
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, 

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

[Rodolfo Campero]

Marko,

2013/11/22 Marko Kreen mark...@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 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], 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

Re: [HACKERS] information schema parameter_default implementation

[Rodolfo Campero]

Review: information schema parameter_default implementation (v2)

This is a review of the patch submitted in
http://archives.postgresql.org/message-id/1384483678.5008.1.ca...@vanquo.pezone.net
(information schema parameter_default implementation).

Previous review from Amit Khandekar covers technical aspects:
http://www.postgresql.org/message-id/CACoZds0eB3-yZ+pVLp9Sf5Xs_9xsDZ=jdp1d83ra-hjvjjo...@mail.gmail.com

Submission review
=
 * Is the patch in a patch format which has context? (eg: context diff
format)
Yes

 * Does it apply cleanly to the current git master?
I had to apply fromdos to remove trailing whitespace.
After that, the patch applies cleanly to HEAD.
Make builds without warnings, except for:

In file included from gram.y:13675:0:
scan.c: In function ‘yy_try_NUL_trans’:
scan.c:10185:23: warning: unused variable ‘yyg’ [-Wunused-variable]

but from previous messages in this mailing list I think that's unrelated to
this patch and normal.
The regression tests all pass successfully against the new patch.

 * Does it include reasonable tests, necessary doc patches, etc?
Yes

Usability review

 * Does the patch actually implement that?
The patch implements the column parameter_default of information schema
view parameters, defined in the SQL:2011 standard.
I could not get a hand to the spec, but I found a document where it is
mentioned: http://msdn.microsoft.com/en-us/library/jj191733(v=sql.105).aspx

 * Do we want that?
I think we do, as it is defined in the spec.

 * Do we already have it?
No

 * Does it follow SQL spec, or the community-agreed behavior?
SQL:2011.

 * Does it include pg_dump support (if applicable)?
N/A

 * Are there dangers?
None AFAICS.

 * Have all the bases been covered?
Yes.

Feature test

 * Does the feature work as advertised?
Yes

 * Are there corner cases the author has failed to consider?
None that I can see.

 * Are there any assertion failures or crashes?
No

Performance review
==
N/A

Coding review
=
I'm not skilled enough to do a code review; see previous review from Amit:
http://www.postgresql.org/message-id/CACoZds0eB3-yZ+pVLp9Sf5Xs_9xsDZ=jdp1d83ra-hjvjjo...@mail.gmail.com



2013/11/21 Peter Eisentraut pete...@gmx.net

 On 11/20/13, 8:39 PM, Rodolfo Campero wrote:
  2013/11/20 Peter Eisentraut pete...@gmx.net mailto:pete...@gmx.net
 
  Updated patch
 
 
  I can't apply the patch; maybe I'm doing something wrong?

 It looks like you are not in the right directory.




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

Re: [HACKERS] information schema parameter_default implementation

[Rodolfo Campero]

Peter,

This patch no longer applies, because CATALOG_VERSION_NO
in src/include/catalog/catversion.h has changed. I touched the patch and
got it to apply without other problems (I haven't built yet).

Regards,


2013/11/14 Peter Eisentraut pete...@gmx.net

 Updated patch attached.

 On Sat, 2013-11-09 at 12:09 +0530, Amit Khandekar wrote:
2) I found the following check a bit confusing, maybe you can make
  it
better
if (!argmodes || argmodes[i] == PROARGMODE_IN || argmodes[i] ==
PROARGMODE_INOUT || argmodes[i] == PROARGMODE_VARIADIC)
  
   Factored that out into a separate helper function.
 
 
  The statement needs to be split into 80 columns width lines.

 done

3) Function level comment for pg_get_function_arg_default() is
missing.
  
   I think the purpose of the function is clear.
 
  Unless a reader goes through the definition, it is not obvious whether
  the second function argument represents the parameter position in
  input parameters or it is the parameter position in *all* the function
  parameters (i.e. proargtypes or proallargtypes). I think at least a
  one-liner description of what this function does should be present.

 done

  
4) You can also add comments inside the function, for example the
comment for the line:
nth = inputargn - 1 - (proc-pronargs - proc-pronargdefaults);
  
   Suggestion?
 
  Yes, it is difficult to understand what's the logic behind this
  calculation, until we go read the documentation related to
  pg_proc.proargdefaults. I think this should be sufficient:
  /*
  * proargdefaults elements always correspond to the last N input
  arguments,
  * where N = pronargdefaults. So calculate the nth_default accordingly.
  */

 done

  There should be an initial check to see if nth_arg is passed a
  negative value. It is used as an index into the argmodes array, so a
  -ve array index can cause a crash. Because
  pg_get_function_arg_default() can now be called by a user also, we
  need to validate the input values. I am ok with returning with an
  error Invalid argument.

 done

  ---
  Instead of :
  deparse_expression_pretty(node, NIL, false, false, 0, 0)
  you can use :
  deparse_expression(node, NIL, false, false)
 
 done



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




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

Re: [HACKERS] information schema parameter_default implementation

[Rodolfo Campero]

2013/11/20 Rodolfo Campero rodolfo.camp...@anachronics.com

 Peter,

 This patch no longer applies, because CATALOG_VERSION_NO
 in src/include/catalog/catversion.h has changed. I touched the patch and
 got it to apply without other problems (I haven't built yet).


Make fails:
[...]
make -C catalog schemapg.h
make[3]: se ingresa al directorio
`/home/rodolfo/trabajo/postgresql/src/backend/catalog'
cd ../../../src/include/catalog  '/usr/bin/perl' ./duplicate_oids
3846
make[3]: *** [postgres.bki] Error 1
[...]

OID = 3846 is duplicated, see:

./src/include/catalog/pg_proc.h:1976:DATA(insert OID = 3846 (
 pg_get_function_arg_default [...]
./src/include/catalog/pg_proc.h:4679:DATA(insert OID = 3846 (
make_date [...]

Re: [HACKERS] information schema parameter_default implementation

[Rodolfo Campero]

2013/11/20 Peter Eisentraut pete...@gmx.net

 Updated patch


I can't apply the patch; maybe I'm doing something wrong?

$ git apply v2-0001-Implement-information_schema.parameters.parameter.patch
v2-0001-Implement-information_schema.parameters.parameter.patch:49:
trailing whitespace.
   CAST((ss.x).n AS sql_identifier) AS dtd_identifier,
v2-0001-Implement-information_schema.parameters.parameter.patch:50:
trailing whitespace.
   CAST(
v2-0001-Implement-information_schema.parameters.parameter.patch:51:
trailing whitespace.
 CASE WHEN pg_has_role(proowner, 'USAGE')
v2-0001-Implement-information_schema.parameters.parameter.patch:52:
trailing whitespace.
  THEN pg_get_function_arg_default(p_oid, (ss.x).n)
v2-0001-Implement-information_schema.parameters.parameter.patch:53:
trailing whitespace.
  ELSE NULL END
error: patch failed: doc/src/sgml/information_schema.sgml:3323
error: doc/src/sgml/information_schema.sgml: patch does not apply
error: patch failed: src/backend/catalog/information_schema.sql:1133
error: src/backend/catalog/information_schema.sql: patch does not apply
error: patch failed: src/backend/utils/adt/ruleutils.c:2266
error: src/backend/utils/adt/ruleutils.c: patch does not apply
error: patch failed: src/include/catalog/catversion.h:53
error: src/include/catalog/catversion.h: patch does not apply
error: patch failed: src/include/catalog/pg_proc.h:1973
error: src/include/catalog/pg_proc.h: patch does not apply
error: patch failed: src/include/utils/builtins.h:665
error: src/include/utils/builtins.h: patch does not apply
error: patch failed: src/test/regress/expected/create_function_3.out:425
error: src/test/regress/expected/create_function_3.out: patch does not apply
error: patch failed: src/test/regress/sql/create_function_3.sql:138
error: src/test/regress/sql/create_function_3.sql: patch does not apply

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

[Rodolfo Campero]

Done, thanks.


2013/10/28 Robert Haas robertmh...@gmail.com

 On Sat, Oct 26, 2013 at 9:17 AM, Rodolfo Campero
 rodolfo.camp...@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

[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