Re: [HACKERS] Auto-explain patch

2008-09-27 Thread Alex Hunsaker
On Wed, Aug 27, 2008 at 8:54 PM, ITAGAKI Takahiro [EMAIL PROTECTED] wrote: Here is a contrib version of auto-explain. I'd like to add it the next commit-fest in September. Here is my review: *custom_guc_flags-0828.patch It seems to be windows newline damaged? lots of ^M at the end of the

Re: [HACKERS] Updates of SE-PostgreSQL 8.4devel patches

2008-09-27 Thread KaiGai Kohei
Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I am confused how knowing that a sequence number used for a primary key exists or doesn't exist is leaking _meaningful_ information. People might know the sequence number exists, but how is that information useful.

Re: [HACKERS] PostgreSQL future ideas

2008-09-27 Thread Chris Browne
[EMAIL PROTECTED] (Jonah H. Harris) writes: On Fri, Sep 26, 2008 at 11:52 AM, Andrew Dunstan [EMAIL PROTECTED] wrote: Speaking of language choice, no one said that _all_ the source code would need to be rewritten. It would be nice, for example, if PostgreSQL rewrote the current GUC system with

Re: [HACKERS] PostgreSQL future ideas

2008-09-27 Thread Andrew Dunstan
Chris Browne wrote: [EMAIL PROTECTED] (Jonah H. Harris) writes: On Fri, Sep 26, 2008 at 11:52 AM, Andrew Dunstan [EMAIL PROTECTED] wrote: Speaking of language choice, no one said that _all_ the source code would need to be rewritten. It would be nice, for example, if PostgreSQL

Re: [HACKERS] PostgreSQL future ideas

2008-09-27 Thread Mark Mielke
Chris Browne wrote: [EMAIL PROTECTED] (Jonah H. Harris) writes: Having done quite a bit of internals work with SAP DB (which is an amalgamation of C, C++, and Pascal), I completely agree. The entire system, if possible, should be in a single language. Note that this actually *isn't*

Re: [HACKERS] PostgreSQL future ideas

2008-09-27 Thread Douglas McNaught
On Sat, Sep 27, 2008 at 12:13 PM, Mark Mielke [EMAIL PROTECTED] wrote: If some parts of PostgreSQL are not performance bottlenecks, and they are extremely complicated to write in C, and very easy to write in something else common and simple (I've never used LUA myself?), I imagine it would be

[HACKERS] Null row vs. row of nulls in plpgsql

2008-09-27 Thread Tom Lane
I looked a bit at the bug report here: http://archives.postgresql.org/pgsql-bugs/2008-09/msg00164.php ISTM that the fundamental problem is that plpgsql doesn't distinguish properly between a null row value (eg, null::somerowtype) and a row of null values (eg, row(null,null,...)::somerowtype).

[HACKERS] Fwd: Null row vs. row of nulls in plpgsql

2008-09-27 Thread Oleg Serov
-- Forwarded message -- From: Oleg Serov [EMAIL PROTECTED] Date: 2008/9/27 Subject: Re: Null row vs. row of nulls in plpgsql To: Tom Lane [EMAIL PROTECTED] I'm newbie, but i think that adding bool flag to PLpgSQL_row isnull will handle the problem(like in PLpgSQL_var); 2008/9/27

Re: [HACKERS] Null row vs. row of nulls in plpgsql

2008-09-27 Thread Hannu Krosing
On Sat, 2008-09-27 at 14:56 -0400, Tom Lane wrote: I looked a bit at the bug report here: http://archives.postgresql.org/pgsql-bugs/2008-09/msg00164.php ISTM that the fundamental problem is that plpgsql doesn't distinguish properly between a null row value (eg, null::somerowtype) and a row