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 of
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 (OI
0
On Fri, Dec 11, 2015 at 12:55 PM, Caleb Welton 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 modify for futur
oid ordering.
> On Dec 11, 2015, at 11:43 AM, Alvaro Herrera wrote:
>
> Caleb Welton wrote:
>> I'm happy working these ideas forward if there is interest.
>>
>> Basic design proposal is:
>> - keep a minimal amount of bootstrap to avoid intrusive c
uding 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 w
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 t
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
/usr/include/stdlib
From: Tom Lane mailto:t...@sss.pgh.pa.us>>
Date: August 19, 2010 10:25:36 AM PDT
To: David Fetter mailto:da...@fetter.org>>
Cc: Kevin Grittner
mailto:kevin.gritt...@wicourts.gov>>, Robert Haas
mailto:robertmh...@gmail.com>>, Pavel Stehule
mailto:pavel.steh...@gmail.com>>, Greg Stark
mailto:gsst
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
hypot
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
expressin
lines of code...
Regards,
Caleb
On 12/1/09 9:24 PM, "Tom Lane" wrote:
Caleb Welton writes:
> On 12/1/09 7:38 PM, "Tom Lane" wrote:
>> Under what circumstances would users (or anyone at all) be putting data into
>> an int2vector?
> What exactly is y
Tom,
Thanks for the comments.
Caleb Welton writes:
> I believe the int2vectorin function should handle invalid input more cleanly.
On 12/1/09 7:38 PM, "Tom Lane" wrote:
>> Why bother?
Because correctness is good. Results that produce unexpected results from
incorrect in
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;
int2vector
On 10/1/09 9:26 PM, "Robert Haas" wrote:
2009/10/1 KaiGai Kohei :
> Robert Haas wrote:
>> On Thu, Oct 1, 2009 at 8:52 PM, Euler Taveira de Oliveira
>> wrote:
>>> David E. Wheeler escreveu:
On Oct 1, 2009, at 3:42 PM, Tom Lane wrote:
> My inclination is to think that the right behav
rds,
Caleb
On 8/22/09 7:03 AM, "Tom Lane" wrote:
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
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
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 t
No. Still no sandbox.
-Caleb
On 5/28/09 6:06 PM, "Andrew Dunstan" 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 people are likely
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 Ca
the comments,
Caleb
On 5/27/09 3:11 AM, "Peter Eisentraut" 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 tur
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 dro
e" <[EMAIL 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 ar
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 join
23 matches
Mail list logo
