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 th
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 mark
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
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 th
Greg Stark writes:
> On Sat, Aug 22, 2009 at 11:45 AM, Caleb Welton 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
On Sat, Aug 22, 2009 at 11:45 AM, Caleb Welton 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 alternative to atta
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 no
2009/8/18 Peter Eisentraut :
> 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
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 indi
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 th
Andrew Dunstan 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.
There's been
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 Schlossn
Peter Eisentraut 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 for this.
For
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
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 betwee
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
Sorry about that. Here it is again as an attachment.
-Caleb
On 7/16/09 7:16 AM, "Peter Eisentraut" 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, it looks lik
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
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" wrote:
Peter Eisentraut writes:
> On Wednesday 27 May 2009 21:53:31 Caleb Welton wrote:
>>
Peter Eisentraut 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 as you sa
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 vari
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 PyIn
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 per
24 matches
Mail list logo
