I believe the int2vectorin function should handle invalid input more cleanly.
Current behavior:
-- Correct input format:
SELECT '1 2 3'::int2vector;
int2vector
1 2 3
(1 row)
-- Three variations on incorrect input format
SELECT '1not 2really_an 3int2vector'::int2vector;
Tom,
Thanks for the comments.
Caleb Welton cwel...@greenplum.com writes:
I believe the int2vectorin function should handle invalid input more cleanly.
On 12/1/09 7:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Why bother?
Because correctness is good. Results that produce unexpected results
, Tom Lane t...@sss.pgh.pa.us wrote:
Caleb Welton cwel...@greenplum.com writes:
On 12/1/09 7:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Under what circumstances would users (or anyone at all) be putting data into
an int2vector?
What exactly is your objection to having the int2arrayin parser
I was dealing with a customer recently who very much wanted this behavior,
during discussions with them
I wrote up a little something describing how different database vendors treat
views and alter statements.
...
Part of the issue here is that the SQL Standard does a very poor job of
This is an area that the SQL standard didn't think through very clearly
(IMHO). They actually have two ways of specifying functions like this, one
is the ordered aggregate section that this syntax is modeled on, which is
indeed very confusing for multi-parameter aggregates. The other is the
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
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
On 10/1/09 9:26 PM, Robert Haas robertmh...@gmail.com wrote:
2009/10/1 KaiGai Kohei kai...@ak.jp.nec.com:
Robert Haas wrote:
On Thu, Oct 1, 2009 at 8:52 PM, Euler Taveira de Oliveira
eu...@timbira.com wrote:
David E. Wheeler escreveu:
On Oct 1, 2009, at 3:42 PM, Tom Lane wrote:
My
Is there any reason that int2_sum, int4_sum, and int8_sum are not marked as
being strict? All the other transition functions for sum, and every other
built in aggregation function is marked as strict, as demonstrated with:
select x.proname, t.proname, t.proisstrict
from ((pg_aggregate a left
PROTECTED] wrote:
Caleb Welton [EMAIL PROTECTED] writes:
Is there any reason that int2_sum, int4_sum, and int8_sum are not marked as
being strict?
They wouldn't work otherwise, because the transition datatypes aren't
the same as the inputs.
regards, tom lane
---(end
From: Tom Lane t...@sss.pgh.pa.usmailto:t...@sss.pgh.pa.us
Date: August 19, 2010 10:25:36 AM PDT
To: David Fetter da...@fetter.orgmailto:da...@fetter.org
Cc: Kevin Grittner
kevin.gritt...@wicourts.govmailto:kevin.gritt...@wicourts.gov, Robert Haas
Hello,
I'm trying to figure out if this is a bug or a feature.
Two child tables, one created with inheritance, one altered to have
inheritance:
create table A(a text, b text);
create table A1() inherits (A);
create table A2(a text, b text);
alter table A2 INHERIT A;
When you
, Peter Eisentraut pete...@gmx.net wrote:
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
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 say it is
better to address that separately.
That was making
No. Still no sandbox.
-Caleb
On 5/28/09 6:06 PM, Andrew Dunstan and...@dunslane.net wrote:
Does Python 3 have some sort of usable sandbox that would mean we could
have a trusted plpython?
Otherwise, I'm not too keen simply to throw Python 2.x overboard until
it's no longer common on platforms
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
A little while back some users started complaining that the contrib module
I develop (MADlib) was failing to build with the following error:
--
/usr/include/postgresql/9.2/server/port.h:480:32: error: declaration of
'char* mkdtemp(char*)' has a different exception specifier
Hello Hackers,
Reviving an old thread on simplifying the bootstrap process.
I'm a developer from the GPDB / HAWQ side of the world where we did some
work a while back to enable catalog definition via SQL files and we have
found it valuable from a dev perspective. The mechanism currently in
, Dec 11, 2015 at 12:55 PM, Caleb Welton <cwel...@pivotal.io> wrote:
> Makes sense.
>
> During my own prototyping what I did was generate the sql statements via
> sql querying the existing catalog. Way easier than hand writing 1000+
> function definitions and not difficult to modi
The current semantic level is pretty low level, somewhat cumbersome, and
requires filling in values that most of the time the system has a pretty
good idea how to fill in default values.
Compare:
CREATE FUNCTION lo_export(oid, text) RETURNS integer LANGUAGE internal
STRICT AS 'lo_export' WITH
Yes, that alone without any other changes would be a marked improvement and
could be implemented in many places, pg_operator is a good example.
... but there is some circularity especially with respect to type
definitions and the functions that define those types. If you changed the
definition
the modifications to pg_proc.h that would follow.
Thanks,
Caleb
On Thu, Dec 10, 2015 at 11:47 AM, Caleb Welton wrote:
>
>
> Hello Hackers,
>
> Reviving an old thread on simplifying the bootstrap process.
>
> I'm a developer from the GPDB / HAWQ side of the world whe
oid ordering.
> On Dec 11, 2015, at 11:43 AM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote:
>
> Caleb Welton wrote:
>> I'm happy working these ideas forward if there is interest.
>>
>> Basic design proposal is:
>> - keep a minimal amount of boots
23 matches
Mail list logo
