On mån, 2009-08-31 at 23:41 +0300, Peter Eisentraut wrote:
On sön, 2009-08-16 at 02:44 +0300, Peter Eisentraut wrote:
The remaining problem is that the patch loses domain checking on the
return types, because some paths no longer go through the data type's
input function. I have marked
On Wed, 2009-05-27 at 14:25 -0700, Caleb Welton wrote:
Yes, in Python = 2.4 there is the Decimal datatype.
However, unlike the other mappings employed by plpythonu, Decimal
requires an import statement to be in scope.
adding it as already-imported module should not be hard
I think that
On sön, 2009-08-16 at 02:44 +0300, Peter Eisentraut wrote:
The remaining problem is that the patch loses domain checking on the
return types, because some paths no longer go through the data type's
input function. I have marked these places as FIXME, and the regression
tests also contain a
On mån, 2009-08-17 at 11:55 -0400, Alvaro Herrera wrote:
Peter Eisentraut wrote:
I have reworked this patch a bit and extended the plpython test suite
around it. Current copy attached.
I think the errcontext bits should be committed separately to get them
out of the way (and to ensure
As documented in the patch, the primary motivation was support of BYTEA
datatype, which when cast through cstring was truncating python strings with
embedded nulls,
performance was only a secondary consideration.
Regards,
Caleb
(Sorry for my slow entry on this thread, I'm on vacation right
On Sat, Aug 22, 2009 at 11:45 AM, Caleb Weltoncwel...@greenplum.com wrote:
As documented in the patch, the primary motivation was support of BYTEA
datatype, which when cast through cstring was truncating python strings with
embedded nulls,
performance was only a secondary consideration.
The
Greg Stark gsst...@mit.edu writes:
On Sat, Aug 22, 2009 at 11:45 AM, Caleb Weltoncwel...@greenplum.com wrote:
As documented in the patch, the primary motivation was support of BYTEA
datatype, which when cast through cstring was truncating python strings with
embedded nulls,
performance was
I didn't say that it _only_ affects bytea, I said that was the _primary
motivation_ for it.
Converting from postgres=python this change affects boolean, float4, float8,
numeric, int16, int32, int64, text, and bytea. The code to handle this goes
through DatumGetXXX for the native C type for
Peter Eisentraut pete...@gmx.net writes:
The remaining problem is that the patch loses domain checking on the
return types, because some paths no longer go through the data type's
input function. I have marked these places as FIXME, and the regression
tests also contain a failing test case
Tom Lane wrote:
For the record, I think this entire patch is a bad idea. PLs should not
be so much in bed with the internal representation of datatypes.
I thought there was some suggestion in the past that we should move some
in that direction. The discussion context was Theo
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
For the record, I think this entire patch is a bad idea. PLs should not
be so much in bed with the internal representation of datatypes.
I thought there was some suggestion in the past that we should move some
in that direction.
Peter Eisentraut wrote:
I have reworked this patch a bit and extended the plpython test suite
around it. Current copy attached.
I think the errcontext bits should be committed separately to get them
out of the way (and to ensure that they get in, regardless of objections
to other parts of the
On mån, 2009-08-17 at 10:42 -0400, Tom Lane wrote:
For the record, I think this entire patch is a bad idea. PLs should not
be so much in bed with the internal representation of datatypes. To
take just one example, this *will* break when/if we change text to carry
some internal locale
2009/8/18 Peter Eisentraut pete...@gmx.net:
On mån, 2009-08-17 at 10:42 -0400, Tom Lane wrote:
For the record, I think this entire patch is a bad idea. PLs should not
be so much in bed with the internal representation of datatypes. To
take just one example, this *will* break when/if we
Primary motivation of the attached patch is to support handling bytea
conversion allowing for embedded nulls, which in turn allows for
supporting the marshal module.
Secondary motivation is slightly improved performance for conversion
routines of basic datatypes that have simple mappings
On Aug 15, 2009, at 4:44 PM, Peter Eisentraut wrote:
What's needed here, I think, is an API that takes a datum plus type
information and checks whether the datum is valid within the domain.
/agree =)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On tis, 2009-05-26 at 16:07 -0700, Caleb Welton wrote:
Patch for plpythonu
Primary motivation of the attached patch is to support handling bytea
conversion allowing for embedded nulls, which in turn allows for
supporting the marshal module.
Secondary motivation is slightly improved
On Wednesday 27 May 2009 02:07:33 Caleb Welton wrote:
Patch for plpythonu
This patch doesn't apply; I think it got mangled during email transport.
(Tabs changed to spaces, it looks like.) Could you resend the patch as a
separate attachment in a way that it doesn't get mangled?
--
Sent via
Sorry about that. Here it is again as an attachment.
-Caleb
On 7/16/09 7:16 AM, Peter Eisentraut pete...@gmx.net wrote:
On Wednesday 27 May 2009 02:07:33 Caleb Welton wrote:
Patch for plpythonu
This patch doesn't apply; I think it got mangled during email transport.
(Tabs changed to spaces,
On Wednesday 27 May 2009 02:07:33 Caleb Welton wrote:
Patch for plpythonu
Primary motivation of the attached patch is to support handling bytea
conversion allowing for embedded nulls, which in turn allows for supporting
the marshal module.
Secondary motivation is slightly improved
All data types should map to the same python object types as they did before,
so int32-PyInt, int64-PyLong, numeric-PyFloat, etc.
The conversion routines are slightly different, eg int32 is initialized via
PyInt_FromLong() instead of first converting the integer to a string then
calling
On Wednesday 27 May 2009 21:53:31 Caleb Welton wrote:
Previously numeric-string-PyFloat_FromString, now
numeric-double-PyFloat_FromDouble, which makes use of postgres
numeric-double routines rather than python string-double routines, and it
is conceivable that there are precision variations
Peter Eisentraut pete...@gmx.net writes:
On Wednesday 27 May 2009 21:53:31 Caleb Welton wrote:
... My own
feeling on the matter is that PyFloat is the wrong mapping for numeric, but
I didn't want to muddy this patch by changing that.
Yeah, that one had me wondering for a while as well, but
Yes, in Python = 2.4 there is the Decimal datatype.
However, unlike the other mappings employed by plpythonu, Decimal requires an
import statement to be in scope.
-Caleb
On 5/27/09 2:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
On Wednesday 27 May 2009
24 matches
Mail list logo
