date:20110123

On Mon, Jan 24, 2011 at 08:45, Fujii Masao  wrote:
> On Fri, Jan 21, 2011 at 12:28 AM, Tom Lane  wrote:
>> Magnus Hagander  writes:
 - Why not initialize logid and logseg like so?:

        int logid = startptr.xlogid;
        int logseg = startptr.xrecoff / XLogSegSize;

  Then use those in your elog?  Seems cleaner to me.
>>
>>> Hmm. Yes. Agreed.
>>
>> Marginal complaint here: int is the wrong type, I'm pretty sure.
>
> And, we should use XLByteToPrevSeg here instead of just =, I think.

Not XLByteToSeg?

(I admit I missed the existance of both those macros, though)

I plan to post a rebased version of this patch today or tomorrow, btw,
that should work against all the changes that have been applied to
git.

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Include WAL in base backup

2011-01-23 Thread Fujii Masao

On Fri, Jan 21, 2011 at 12:28 AM, Tom Lane  wrote:
> Magnus Hagander  writes:
>>> - Why not initialize logid and logseg like so?:
>>>
>>>        int logid = startptr.xlogid;
>>>        int logseg = startptr.xrecoff / XLogSegSize;
>>>
>>>  Then use those in your elog?  Seems cleaner to me.
>
>> Hmm. Yes. Agreed.
>
> Marginal complaint here: int is the wrong type, I'm pretty sure.

And, we should use XLByteToPrevSeg here instead of just =, I think.

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SSI, simplified

2011-01-23 Thread Heikki Linnakangas


On 24.01.2011 03:48, Kevin Grittner wrote:

If I get a solid answer on the SSI/HS issue before I post V14, I
might be able to cover that, too, in that patch.  I haven't wanted to
totally write off the possibility of integrating them as long as
discussion was ongoing; but if someone wants to assume the voice of
Dr. McCoy and declare "It's dead, Jim," I can move on for now and
come back to the issue for 9.2.


It's dead, Jim.

Even if it wasn't, it'd still make sense to leave it out of the first 
commit, and add as later patch. So in any case, the first commit should 
just throw an error.



Oddly, the computer generated voice sorta mangled something near the
beginning, which was supposed to be "I'm psyched", but sorta sounds
like "I'm sorry".  Computers -- you just can't rely on 'em.  I hope
people find it entertaining and at least slightly informative.  :-)

http://www.xtranormal.com/watch/8285377/?listid=20642536


Wow, that's hilarious! :-)

--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Tracking latest timeline in standby mode

2011-01-23 Thread Fujii Masao

On Wed, Jan 5, 2011 at 5:08 AM, Heikki Linnakangas
 wrote:
> I finally got around to look at this. I wrote a patch to validate that the
> TLI on xlog page header matches ThisTimeLineID during recovery, and noticed
> quickly in testing that it doesn't catch all the cases I'd like to catch
> :-(.

The patch added into the CF hasn't solved this problem yet. Are you planning
to solve it in 9.1? Or are you planning to just commit the patch for 9.1, and
postpone the issue to 9.2 or later? I'm OK either way. Of course, the former
is quite better, though.

Anyway, you have to add the documentation about this feature.

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] add attribute((noreturn)) to suppress a waring

2011-01-23 Thread Heikki Linnakangas


On 24.01.2011 03:42, Itagaki Takahiro wrote:

I found the following warning with Fedora 14 / gcc 4.5.1.

pg_backup_archiver.c: In function ‘_discoverArchiveFormat’:
pg_backup_archiver.c:1736:11: warning: ‘fh’ may be used uninitialized
in this function

To suppress it, I'm thinking to add noreturn to die_horribly().
Any objections?  Another solution might be adding a dummy assignment
after calls of die_horribly().


I added a dummy assignment, that's how we've handled this before in 
pg_dump. I guess we could use noreturn, we already use it in pg_re_throw 
function. But we also have a dummy exit(1) call in the PG_RE_THROW macro 
for non-gcc compilers, so we might need to do that here too.


Thanks!

--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pg_basebackup for streaming base backups

2011-01-23 Thread Fujii Masao

On Sun, Jan 23, 2011 at 8:33 PM, Magnus Hagander  wrote:
> I've committed this with the current name, pg_basebackup

Great!

But, per subsequent commit logs, I should have reviewed more about
portability issues :(

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Is there a way to build PostgreSQL client libraries with MinGW

And there are two versions of gcc installed on my WinXP PRO SP3, 3.4.4
is the one used to the above test

D:\devproj\postgresql-9.0.2>gcc -v
Reading specs from /usr/lib/gcc/i686-pc-msys/3.4.4/specs
Configured with: /home/cstrauss/build/gcc3/gcc-3.4.4/configure --prefix=/usr --s
ysconfdir=/etc --localstatedir=/var --infodir=/share/info --mandir=/share/man --
libexecdir=/lib --enable-languages=c,c++ --disable-nls --enable-threads=posix --
enable-sjlj-exceptions --enable-hash-synchronization --enable-libstdcxx-debug --
with-newlib
Thread model: posix
gcc version 3.4.4 (msys special)

D:\devproj\postgresql-9.0.2>


D:\Amber\Program\Rtools211\MinGW\bin>gcc -v
Using built-in specs.
COLLECT_GCC=gcc
Target: mingw32
Configured with: ../gcc-4.5.0/configure --enable-languages=c,c++,ada,fortran,obj
c,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgo
mp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-r
untime-libs --disable-werror --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.5.0 (GCC)

D:\Amber\Program\Rtools211\MinGW\bin>

On Mon, Jan 24, 2011 at 1:17 PM, Xiaobo Gu  wrote:
> Hi,
> I download the lastest 32bit MinGW from sourceforge, and found there
> are *NIX like tools such as chmod and ls in the MinGW\msys\1.0\bin
> directory.
>
>
> But the make process does not success,
>
> This test is done on my 32bit Windows XP SP3
>
> Here are the messages:
>
> D:\devproj\postgresql-9.0.2>sh configure --without-zlib
> ..
>
> D:\devproj\postgresql-9.0.2>ls
> 2011-01-24  13:14              .
> 2011-01-24  13:14              ..
> 2010-12-14  10:55               233 .gitignore
> 2010-12-14  10:55               445 aclocal.m4
> 2011-01-24  11:12              config
> 2011-01-24  13:14           478,602 config.log
> 2011-01-24  13:14            36,977 config.status
> 2010-12-14  10:55           844,733 configure
> 2010-12-14  10:55            60,877 configure.in
> 2011-01-24  12:06           840,095 configure.lineno
> 2011-01-24  11:12              contrib
> 2010-12-14  10:55             1,192 COPYRIGHT
> 2011-01-24  11:12              doc
> 2011-01-24  13:14             3,760 GNUmakefile
> 2010-12-14  10:55             3,760 GNUmakefile.in
> 2010-12-14  11:21           968,292 HISTORY
> 2010-12-14  11:21            79,024 INSTALL
> 2010-12-14  10:55             1,477 Makefile
> 2010-12-14  10:55             1,287 README
> 2011-01-24  13:14              src
>
> D:\devproj\postgresql-9.0.2>make
> make -C src all
> make[1]: Entering directory `/d/devproj/postgresql-9.0.2/src'
> make -C port all
> make[2]: Entering directory `/d/devproj/postgresql-9.0.2/src/port'
> gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith 
> -Wdeclaration-after-statement
>  -Wendif-labels -fno-strict-aliasing -fwrapv -I../../src/port -DFRONTEND 
> -I../..
> /src/include -I./src/include/port/win32 -DEXEC_BACKEND  
> "-I../../src/include/por
> t/win32"  -c -o fseeko.o fseeko.c
> gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith 
> -Wdeclaration-after-statement
>  -Wendif-labels -fno-strict-aliasing -fwrapv -I../../src/port -DFRONTEND 
> -I../..
> /src/include -I./src/include/port/win32 -DEXEC_BACKEND  
> "-I../../src/include/por
> t/win32"  -c -o crypt.o crypt.c
> In file included from ../../src/include/pg_config_os.h:22,
>                 from ../../src/include/c.h:90,
>                 from crypt.c:44:
> /usr/lib/gcc/i686-pc-msys/3.4.4/../../../../include/w32api/winsock2.h:103:2: 
> war
> ning: #warning "fd_set and associated macros have been defined in sys/types.
>  This may cause runtime problems with W32 sockets"
> In file included from ../../src/include/c.h:90,
>                 from crypt.c:44:
> ../../src/include/pg_config_os.h:28:20: direct.h: No such file or directory
> ../../src/include/pg_config_os.h:90:1: warning: "EIDRM" redefined
> In file included from /usr/include/errno.h:1,
>                 from ../../src/include/c.h:80,
>                 from crypt.c:44:
> /usr/include/sys/errno.h:64:1: warning: this is the location of the previous 
> def
> inition
> In file included from ../../src/include/c.h:90,
>                 from crypt.c:44:
> ../../src/include/pg_config_os.h:165:1: warning: "SIGABRT" redefined
> In file included from /usr/include/signal.h:8,
>                 from ../../src/include/pg_config_os.h:26,
>                 from ../../src/include/c.h:90,
>                 from crypt.c:44:
> /usr/include/sys/signal.h:225:1: warning: this is the location of the 
> previous d
> efinition
> In file included from ../../src/include/c.h:90,
>                 from crypt.c:44:
> ../../src/include/pg_config_os.h:222: error: conflicting types for 'uid_t'
> /usr/include/sys/types.h:133: error: previous declaration of 'uid_t' was here
> ../../src/include/pg_config_os.h:223: error: conflicting types for 'gid_t'
> /usr/include/sys/types.h:134: error: previous declaration of 'gid_t' was here
> In file included from ../../src/include/c.h:90,
>                 from crypt.c:44:

Re: [HACKERS] Is there a way to build PostgreSQL client libraries with MinGW

Hi,
I download the lastest 32bit MinGW from sourceforge, and found there
are *NIX like tools such as chmod and ls in the MinGW\msys\1.0\bin
directory.


But the make process does not success,

This test is done on my 32bit Windows XP SP3

Here are the messages:

D:\devproj\postgresql-9.0.2>sh configure --without-zlib
..

D:\devproj\postgresql-9.0.2>ls
2011-01-24  13:14  .
2011-01-24  13:14  ..
2010-12-14  10:55   233 .gitignore
2010-12-14  10:55   445 aclocal.m4
2011-01-24  11:12  config
2011-01-24  13:14   478,602 config.log
2011-01-24  13:1436,977 config.status
2010-12-14  10:55   844,733 configure
2010-12-14  10:5560,877 configure.in
2011-01-24  12:06   840,095 configure.lineno
2011-01-24  11:12  contrib
2010-12-14  10:55 1,192 COPYRIGHT
2011-01-24  11:12  doc
2011-01-24  13:14 3,760 GNUmakefile
2010-12-14  10:55 3,760 GNUmakefile.in
2010-12-14  11:21   968,292 HISTORY
2010-12-14  11:2179,024 INSTALL
2010-12-14  10:55 1,477 Makefile
2010-12-14  10:55 1,287 README
2011-01-24  13:14  src

D:\devproj\postgresql-9.0.2>make
make -C src all
make[1]: Entering directory `/d/devproj/postgresql-9.0.2/src'
make -C port all
make[2]: Entering directory `/d/devproj/postgresql-9.0.2/src/port'
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement
 -Wendif-labels -fno-strict-aliasing -fwrapv -I../../src/port -DFRONTEND -I../..
/src/include -I./src/include/port/win32 -DEXEC_BACKEND  "-I../../src/include/por
t/win32"  -c -o fseeko.o fseeko.c
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement
 -Wendif-labels -fno-strict-aliasing -fwrapv -I../../src/port -DFRONTEND -I../..
/src/include -I./src/include/port/win32 -DEXEC_BACKEND  "-I../../src/include/por
t/win32"  -c -o crypt.o crypt.c
In file included from ../../src/include/pg_config_os.h:22,
 from ../../src/include/c.h:90,
 from crypt.c:44:
/usr/lib/gcc/i686-pc-msys/3.4.4/../../../../include/w32api/winsock2.h:103:2: war
ning: #warning "fd_set and associated macros have been defined in sys/types.
  This may cause runtime problems with W32 sockets"
In file included from ../../src/include/c.h:90,
 from crypt.c:44:
../../src/include/pg_config_os.h:28:20: direct.h: No such file or directory
../../src/include/pg_config_os.h:90:1: warning: "EIDRM" redefined
In file included from /usr/include/errno.h:1,
 from ../../src/include/c.h:80,
 from crypt.c:44:
/usr/include/sys/errno.h:64:1: warning: this is the location of the previous def
inition
In file included from ../../src/include/c.h:90,
 from crypt.c:44:
../../src/include/pg_config_os.h:165:1: warning: "SIGABRT" redefined
In file included from /usr/include/signal.h:8,
 from ../../src/include/pg_config_os.h:26,
 from ../../src/include/c.h:90,
 from crypt.c:44:
/usr/include/sys/signal.h:225:1: warning: this is the location of the previous d
efinition
In file included from ../../src/include/c.h:90,
 from crypt.c:44:
../../src/include/pg_config_os.h:222: error: conflicting types for 'uid_t'
/usr/include/sys/types.h:133: error: previous declaration of 'uid_t' was here
../../src/include/pg_config_os.h:223: error: conflicting types for 'gid_t'
/usr/include/sys/types.h:134: error: previous declaration of 'gid_t' was here
In file included from ../../src/include/c.h:90,
 from crypt.c:44:
../../src/include/pg_config_os.h:251:1: warning: "EMSGSIZE" redefined
In file included from /usr/include/errno.h:1,
 from ../../src/include/c.h:80,
 from crypt.c:44:
/usr/include/sys/errno.h:132:1: warning: this is the location of the previous de
finition
In file included from ../../src/include/c.h:90,
 from crypt.c:44:
../../src/include/pg_config_os.h:252:1: warning: "EAFNOSUPPORT" redefined
In file included from /usr/include/errno.h:1,
 from ../../src/include/c.h:80,
 from crypt.c:44:
/usr/include/sys/errno.h:116:1: warning: this is the location of the previous de
finition
In file included from ../../src/include/c.h:90,
 from crypt.c:44:
../../src/include/pg_config_os.h:253:1: warning: "EWOULDBLOCK" redefined
In file included from /usr/include/errno.h:1,
 from ../../src/include/c.h:80,
 from crypt.c:44:
/usr/include/sys/errno.h:150:1: warning: this is the location of the previous de
finition
In file included from ../../src/include/c.h:90,
 from crypt.c:44:
../../src/include/pg_config_os.h:254:1: warning: "ECONNRESET" redefined
In file included from /usr/include/errno.h:1,
 from ../../src/include/c.h:80,
 from crypt.c:44:
/usr/inclu

Re: [HACKERS] ALTER TYPE 2: skip already-provable no-work rewrites

2011-01-23 Thread Noah Misch

On Sun, Jan 23, 2011 at 12:06:43PM -0500, Tom Lane wrote:
> Robert Haas  writes:
> > On Sun, Jan 9, 2011 at 5:01 PM, Noah Misch  wrote:
> >> As unintended fallout, it's no longer an error to add oids or a column 
> >> with a
> >> default value to a table whose rowtype is used in columns elsewhere.  This 
> >> seems
> >> best.  Defaults on the origin table do not even apply to new inserts into 
> >> such a
> >> column, and the rowtype does not gain an OID column via its table.
> 
> > I think this should be split into two patches (we can discuss both on
> > this thread, no need to start any new ones), one that implements just
> > the above improvement and another that accomplishes the main purpose
> > of the patch.
> 
> I haven't been paying much attention to this thread, but I happened to
> read the above, and quite frankly it scares the cr*p out of me.  I don't
> believe that Noah even begins to be qualified to understand the
> implications of adding/removing an OID column, and I clearly remember
> the non-obvious bugs we've had in the past from that.  Before this goes
> in I want to see a convincing explanation (not an unsupported assertion)
> why this isn't going to re-introduce those old bugs.

Turns out that we do set HEAP_HASOID and allocate space for an OID in the
composite-type datums.  We don't actually assign an OID, and I can't see any way
to read it from the composite.  It seems most consistent with the verdict of
commit 6d1e361 to continue rejecting these cases.  Thanks for the heads-up.

> I'm also pretty unclear on why it's a good idea to let uses of a rowtype
> be different from the table on which it's allegedly based.  To the
> extent that the current behavior allows that, isn't that a bug rather
> than a feature we should extend?

>From the perspective of defining the behavior afresh, I'd agree.  I haven't 
>seen
any stirrings of actually implementing this, though.  Like Robert, I'm doubting
there's a user benefit from rejecting these cases in preparation for the day
that they would actually require it.

nm

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] REVIEW: PL/Python table functions

2011-01-23 Thread Hitoshi Harada

2011/1/23 Jan Urbański :
> On 22/01/11 11:15, Hitoshi Harada wrote:
>> This is a review for 
>> https://commitfest.postgresql.org/action/patch_view?id=460
>
> Thanks,
>
>> One issue is typmod of record type.
>>
>> regression=# create or replace function func1(t text) returns record
>> as $$ return {'name': t, 'value': 0} $$ language plpythonu;
>> regression=# select * from func1('jan') as (name text, value bigint);
>>  name | value
>> --+---
>>  jan  |     0
>> (1 row)
>>
>> regression=# select * from func1('jan') as (name text, value int);
>> ERROR:  function return row and query-specified return row do not match
>> DETAIL:  Returned type bigint at ordinal position 2, but query expects 
>> integer.
>
> That's a bug, thanks for spotting it.
>
>> It seems that typmod of PLyTypeInfo is not updated over statements
>> within the session. I saw the error doesn't occur when I re-connect to
>> the backend after the error.
>
> I tracked it down to caching the I/O functions for the return type. Your
> example shows that you can't just discover the output record type once,
> but you have to recheck whether the returned record's structure has not
> changed between calls.
>
> I implemented it by looping over the attributes of the output record and
> checking if type for which we have already cached the I/O function is
> binary coercible to the type that's actually in the record. This allows
> the code to skip recaching the functions in the common case when the
> record stays the same, and fixes the bug you found.
>
> Attached is a new patch for table function support and an incremental
> patch with the change I did. The new patch for table functions does not
> apply to HEAD, it's a refinement of the previous table-functions patch.
> After the refactor patches are all applied or rejected, I'll post a
> frech patch that applies cleanly to HEAD.

I tested the new incremental patch and the previous example works
fine. I don't know if this can be handled properly but another example
is:

regression=# create function func1(t text) returns record as $$ return
{'name':t, 'value':0}; $$ language plpythonu ;
CREATE FUNCTION
regression=# select * from func1('jan') as (name text, value bigint);
 name | value
--+---
 jan  | 0
(1 row)

regression=# select * from func1('jan') as (value text, name bigint);
 value | name
---+--
 jan   |0
(1 row)

where value and name don't point to the correct data. Your
data-type-check logic might not be enough.

Regards,


-- 
Hitoshi Harada

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] ALTER TYPE 2: skip already-provable no-work rewrites

On Sun, Jan 23, 2011 at 12:06 PM, Tom Lane  wrote:
> Robert Haas  writes:
>> On Sun, Jan 9, 2011 at 5:01 PM, Noah Misch  wrote:
>>> As unintended fallout, it's no longer an error to add oids or a column with 
>>> a
>>> default value to a table whose rowtype is used in columns elsewhere.  This 
>>> seems
>>> best.  Defaults on the origin table do not even apply to new inserts into 
>>> such a
>>> column, and the rowtype does not gain an OID column via its table.
>
>> I think this should be split into two patches (we can discuss both on
>> this thread, no need to start any new ones), one that implements just
>> the above improvement and another that accomplishes the main purpose
>> of the patch.
>
> I haven't been paying much attention to this thread, but I happened to
> read the above, and quite frankly it scares the cr*p out of me.  I don't
> believe that Noah even begins to be qualified to understand the
> implications of adding/removing an OID column, and I clearly remember
> the non-obvious bugs we've had in the past from that.  Before this goes
> in I want to see a convincing explanation (not an unsupported assertion)
> why this isn't going to re-introduce those old bugs.

Because all of our old bugs now have regression tests that will break
if we reintroduce them?

I guess that probably falls into the category of "wishful thinking".

> I'm also pretty unclear on why it's a good idea to let uses of a rowtype
> be different from the table on which it's allegedly based.  To the
> extent that the current behavior allows that, isn't that a bug rather
> than a feature we should extend?

It's not clear to me what it would mean for OIDs or default values to
propagate themselves to the table's row type.  Check constraints,
foreign keys, unique constraints, etc. don't either.  In fact, not
even the NOT NULL property flows through.  On the surface, preventing
these details from interfering with ALTER TABLE commands that can't
actually break anything seems like removing an annoying implementation
restriction, but I guess one could make the argument that we actually
intend to make those flow through some day.  But if so, this is the
first I'm hearing of it.

>>> # The fact that ALTER TYPE requires rewriting the whole table is
>>> sometimes an advantage, because the rewriting process
>>> # eliminates any dead space in the table.
>
>> I'm not sure what we can recommend here instead.
>
> New-style VACUUM FULL.  I don't think that a patch that makes it harder
> to use ALTER TABLE this way is a problem in itself, now that we've got
> that.

Cool.  That'll reclaim space from dropped columns and stuff?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Is there a way to build PostgreSQL client libraries with MinGW

Yes, I want it working on 64 bit Windows Server 2003 R2 and 64 bit
Windows 7 home basic.
Which version of 32bit MinGW  do you use, I use the one shipped with
Rtools212.exe which is downloaded from
http://www.murdoch-sutherland.com/Rtools, and there is no chmod.

xiaobo gu


2011/1/24 Andrew Dunstan :
>
>
> On 01/23/2011 10:09 PM, Xiaobo Gu wrote:
>> Here is my plan,
>> 1. To make the configurate script pass:
>>       Currently MinGW does not provide chmod, but on Windows I think this
>> can be ignored now, we all use Admin
>>       users to do the work.
>> 2. To make a pg-client Makefile target, can you help wich which c
>> files should be compiled and linked into dlls and lib file.
>>
>
>
> Why do you need to do this? Postgres can be built as is today on Mingw.
> Not just the client libraries, the whole server too. It does not need to
> be an Adminstrative user, and you should by no means assume that the
> user building Postgres will be an administrator, nor that the user
> running Postgres will be. My 32 bit Mingw certainly understands chmod.
>
> There are machines doing this every day, several times a day. See
>  - frogmouth and
> narwhal are examples. We've had working Mingw builds for quite a few
> years now.
>
> The only issue is building 64bit binaries. So get the build working for
> 32bit, then try switching to the 64bit compiler and see what breaks. If
> all you need is the client library, build with no zlib or any other
> third party libraries.
>
> cheers
>
> andrew
>

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] patch: Add PGXS support to hstore's Makefile (trivial)

On Sun, Jan 23, 2011 at 9:20 PM, Joseph Adams
 wrote:
> The attached patch changes hstore's Makefile so it is like the others.

Thanks, committed.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] REVIEW: WIP: plpgsql - foreach in

2011-01-23 Thread Stephen Frost

* Robert Haas (robertmh...@gmail.com) wrote:
> Uh oh.  You just reopened the can of worms from hell.

Alright..  I'm missing what happened to this suggestion of using:

FOR var in ARRAY array_expression ...

I like that a lot more than inventing a new top-level keyword, for the
same reasons that Tom mentioned: using a different initial keyword
makes it awkward to make generic statements about "all types of FOR
loop" (as I noticed while looking through the documentation changes that
should be made for this); and also some of the other comments about how
FOREACH doesn't give you any clue that this is some
array-specific-FOR-loop-thingy.

Thanks,

Stephen




signature.asc
Description: Digital signature

Re: [HACKERS] REVIEW: WIP: plpgsql - foreach in

2011-01-23 Thread Stephen Frost

* Robert Haas (robertmh...@gmail.com) wrote:
> On Sun, Jan 23, 2011 at 9:49 PM, Stephen Frost  wrote:
> > Why are you using 'FOREACH' here instead of just making it another
> > variation of 'FOR'?
> 
> Uh oh.  You just reopened the can of worms from hell.

hahahaha.  Apparently I missed that discussion; also wasn't linked off
the patch. :/  Guess I'll go poke through the archives...  Struck me as
obviously wrong to invent something completely new for this, but..

Thanks,

Stephen

signature.asc
Description: Digital signature

Re: [HACKERS] REVIEW: WIP: plpgsql - foreach in

On Sun, Jan 23, 2011 at 9:49 PM, Stephen Frost  wrote:
> Pavel,
>
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> I merge your changes and little enhanced comments.
>
> Thanks.  Reviewing this further-
>
> Why are you using 'FOREACH' here instead of just making it another
> variation of 'FOR'?

Uh oh.  You just reopened the can of worms from hell.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] sepgsql contrib module

On Sun, Jan 23, 2011 at 9:56 PM, Robert Haas  wrote:
> On Sun, Jan 23, 2011 at 8:53 PM, Robert Haas  wrote:
>> 2011/1/21 KaiGai Kohei :
>>> The attached patch is a revised version.
>>
>> I've committed this.  Cleanup coming...
>
> Yikes.  On further examination, exec_object_restorecon() is pretty
> bogus.  Surely you need some calls to quote_literal_cstr() in there
> someplace.  And how about using getObjectDescriptionOids() for the
> error message, instead of the entirely bogus construction that's there
> now?

Also, shouldn't a bunch of these messages end in ": %m"?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Is there a way to build PostgreSQL client libraries with MinGW

2011-01-23 Thread Andrew Dunstan

On 01/23/2011 10:09 PM, Xiaobo Gu wrote:
> Here is my plan,
> 1. To make the configurate script pass:
>   Currently MinGW does not provide chmod, but on Windows I think this
> can be ignored now, we all use Admin
>   users to do the work.
> 2. To make a pg-client Makefile target, can you help wich which c
> files should be compiled and linked into dlls and lib file.
>

Why do you need to do this? Postgres can be built as is today on Mingw.
Not just the client libraries, the whole server too. It does not need to
be an Adminstrative user, and you should by no means assume that the
user building Postgres will be an administrator, nor that the user
running Postgres will be. My 32 bit Mingw certainly understands chmod.

There are machines doing this every day, several times a day. See
 - frogmouth and
narwhal are examples. We've had working Mingw builds for quite a few
years now.

The only issue is building 64bit binaries. So get the build working for
32bit, then try switching to the 64bit compiler and see what breaks. If
all you need is the client library, build with no zlib or any other
third party libraries.

cheers

andrew

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Re: 答复: [HACKERS] Is there a way to build PostgreSQL client libraries with MinGW

Here is my plan,
1. To make the configurate script pass:
Currently MinGW does not provide chmod, but on Windows I think this
can be ignored now, we all use Admin
users to do the work.
2. To make a pg-client Makefile target, can you help wich which c
files should be compiled and linked into dlls and lib file.

Xiaobo Gu

2011/1/23 XiaoboGu :
> Hi
>
> I am not so familiar with the PostgreSQL development team, but using a MinGW
> compatible client side is important to us, so I'd like to start doing it
> myself if any of you experts can help.
>
> Cheers
>
> Xiaobo Gu
>
>> -邮件原件-
>> 发件人: Andrew Dunstan [mailto:and...@dunslane.net]
>> 发送时间: 2011年1月21日 23:25
>> 收件人: Magnus Hagander
>> 抄送: Robert Haas; XiaoboGu; pgsql-hackers@postgresql.org
>> 主题: Re: [HACKERS] Is there a way to build PostgreSQL client libraries
> with MinGW
>>
>>
>>
>> On 01/21/2011 05:24 AM, Magnus Hagander wrote:
>> >>
>> >> That advice needs to be taken with a grain or two of salt. First, while
> you
>> >> probably should not use Cygwin postgres as a production server, it is
> still
>> >> the best way to run psql on Windows that I know of. And second, the
> stuff
>> > Yeah, I agree for psql the client tool (though it used to suck badly
>> > if you were in a non-english locale, but they may have fixed that).
>> > But not for PostgreSQL the full product. I guess we could add a
>> > sentence about the client side, but it needs to be clear that the
>> > non-sucky part only applies to the client.
>>
>>
>> It's not so bad it can't be used for development, and I have known
>> people who do that, and indeed I have deployed one very complex app
>> developed in just that way.
>>
>> More importantly from my POV, there is no support in the buildfarm for
>> just building the client side, and I have no intention of providing it.
>> So it's not insignificant for us to be able to continue supporting a
>> complete build on Cygwin, however much you dislike it.
>>
>>
>> >
>> >> about not being able to generate 64-bit binaries with Mingw is no
> longer
>> >> true (that's why it's no longer called Mingw32), although it is true
> that
>> >> nobody I know has yet tried to do so. It's on my long TODO list, and
> well
>> >> worth doing. (Relying on one compiler is the techno equivalent of
>> >> monolingualism, which my sister's bumper sticker used to tell me is a
>> >> curable condition.)
>> > It's true from the perspective of *postgresql* - you can't use those
>> > compiler to generate 64-bit binaries of PostgreSQL. And it's referring
>> > to "these builds", not the compiler itself.
>> >
>> > And I'm certainly not going to stand in the way of somebody adding
>> > build support for it if they (you or others) want to spend time on it
>> > - that patch should just include an update to that documentation
>> > paragraph, of course.
>> >
>> > Personally, I'm going to put what time I can put into "windows build
>> > system updates" into making us work with VS 2010 because I find that
>> > more important - but that's just me personally.
>> >
>>
>>
>> VS2010 is important, no doubt. But clearly there's some demand for
>> continued Mingw support, hence the OP's question.
>>
>> As I've remarked before, I think we should support as many build
>> platforms/environments as we can.
>>
>> cheers
>>
>> andrew
>
>

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] sepgsql contrib module

On Sun, Jan 23, 2011 at 8:53 PM, Robert Haas  wrote:
> 2011/1/21 KaiGai Kohei :
>> The attached patch is a revised version.
>
> I've committed this.  Cleanup coming...

Yikes.  On further examination, exec_object_restorecon() is pretty
bogus.  Surely you need some calls to quote_literal_cstr() in there
someplace.  And how about using getObjectDescriptionOids() for the
error message, instead of the entirely bogus construction that's there
now?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] REVIEW: WIP: plpgsql - foreach in

2011-01-23 Thread Stephen Frost

Pavel,

* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> I merge your changes and little enhanced comments.

Thanks.  Reviewing this further-

Why are you using 'FOREACH' here instead of just making it another
variation of 'FOR'?  What is 'FOUND' set to following this?  I realize
that might make the code easier, but it really doesn't seem to make much
sense to me from a usability point of view.

There also appears to be some extra whitespace changes that aren't
necessary and a number of places where you don't follow the indentation
conventions (eg: variable definitions in exec_stmt_foreach_a()).

I'm still not really thrilled with how the checking for scalar vs.
array, etc, is handled.  Additionally, what is this? :

else if (stmt->row != NULL)
{   
ctrl_var = estate->datums[stmt->row->dno];
}
else
{
ctrl_var = estate->datums[stmt->rec->dno];
}

Other comments- I don't like using 'i' and 'j', you really should use
better variable names, especially in large loops which contain other
loops.  I'd also suggest changing the outer loop to be equivilant to the
number of iterations that will be done instead of the number of items
and then to *not* update 'i' inside the inner-loop.  That structure is
really just confusing, imv (I certainly didn't entirely follow what was
happening there the first time I read it).  Isn't there a function you
could use to pull out the array slice you need on each iteration through
the array?

Thanks,

Stephen


signature.asc
Description: Digital signature

[HACKERS] patch: Add PGXS support to hstore's Makefile (trivial)

2011-01-23 Thread Joseph Adams

I discovered today that hstore's Makefile currently does not support
PGXS; namely, the ability to install it like so:

USE_PGXS=1 make
sudo USE_PGXS=1 make install

Moreover, hstore is the *only* contrib module whose Makefile does not
contain "PGXS".

The attached patch changes hstore's Makefile so it is like the others.
 I have tested the above commands on a copy of the hstore directory
located outside of the PostgreSQL source tree, and it appears to work
just fine.  I also tested conventional make and make install, and it
still appears to work as well.


Joey Adams
commit a7384288531ba9a235292836d6ee1e17a65a3997
Author: Joey Adams 
Date:   Sun Jan 23 21:05:03 2011 -0500

Added PGXS support to contrib/hstore/Makefile

diff --git a/contrib/hstore/Makefile b/contrib/hstore/Makefile
index e466b6f..1d533fd 100644
--- a/contrib/hstore/Makefile
+++ b/contrib/hstore/Makefile
@@ -1,9 +1,5 @@
 # contrib/hstore/Makefile
 
-subdir = contrib/hstore
-top_builddir = ../..
-include $(top_builddir)/src/Makefile.global
-
 MODULE_big = hstore
 OBJS = hstore_io.o hstore_op.o hstore_gist.o hstore_gin.o hstore_compat.o \
 	crc32.o
@@ -12,4 +8,13 @@ DATA_built = hstore.sql
 DATA = uninstall_hstore.sql
 REGRESS = hstore
 
+ifdef USE_PGXS
+PG_CONFIG = pg_config
+PGXS := $(shell $(PG_CONFIG) --pgxs)
+include $(PGXS)
+else
+subdir = contrib/hstore
+top_builddir = ../..
+include $(top_builddir)/src/Makefile.global
 include $(top_srcdir)/contrib/contrib-global.mk
+endif

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] sepgsql contrib module

2011/1/21 KaiGai Kohei :
> The attached patch is a revised version.

I've committed this.  Cleanup coming...

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] SSI, simplified

2011-01-23 Thread Kevin Grittner

Dan is still beating up on the latest patch with DBT-2, but I expect
that I'll be posting a patch tomorrow with all known issues fixed, no
known bugs, and reasonable performance -- except for the issue of how
this work relates to hot standby in the 9.1 release.  (We did find
and fix a few bugs after V13, although most of our changes have been
tweaking comments, and the bug fixes have mostly consisted of moving
LW lock statements up or down a few lines.)
 
If I get a solid answer on the SSI/HS issue before I post V14, I
might be able to cover that, too, in that patch.  I haven't wanted to
totally write off the possibility of integrating them as long as
discussion was ongoing; but if someone wants to assume the voice of
Dr. McCoy and declare "It's dead, Jim," I can move on for now and
come back to the issue for 9.2.
 
In the mean time, I've been pondering the fact that many of those
posting on SSI issues apparently haven't read even the Overview
section of the Wiki page.
 
http://wiki.postgresql.org/wiki/Serializable
 
I know how busy people are, so (inspired by the both the Geico
commercial which they boast was put together on the xtranormal sight
in 15 minutes or less, and the old favorite book "Einstein
Simplified") I've put together an animated "movie" which punches a
few key points from the overview in less than three minutes.
Hopefully, what it lacks in detail it makes up for with brevity and
humor.
 
Oddly, the computer generated voice sorta mangled something near the
beginning, which was supposed to be "I'm psyched", but sorta sounds
like "I'm sorry".  Computers -- you just can't rely on 'em.  I hope
people find it entertaining and at least slightly informative.  :-)
 
http://www.xtranormal.com/watch/8285377/?listid=20642536
 
I could have just kept on going, but I decided at the start that it
had to be less than three minutes.  Also, please make allowances for
the fact that while I went over 15 minutes putting that "movie"
together, it wasn't by all that much
 
-Kevin

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] add attribute((noreturn)) to suppress a waring

2011-01-23 Thread Itagaki Takahiro

I found the following warning with Fedora 14 / gcc 4.5.1.

pg_backup_archiver.c: In function ‘_discoverArchiveFormat’:
pg_backup_archiver.c:1736:11: warning: ‘fh’ may be used uninitialized
in this function

To suppress it, I'm thinking to add noreturn to die_horribly().
Any objections?  Another solution might be adding a dummy assignment
after calls of die_horribly().

-- 
Itagaki Takahiro


noreturn.diff
Description: Binary data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED

2011-01-23 Thread Kevin Grittner

Tom Lane  wrote:

> I seem to recall pointing out upthread that the FK check triggers
> are designed on the assumption that the constraint does hold
> currently.  Has any analysis been done on exactly how badly they'll
> fail when it doesn't hold? I remain unconvinced that this behavior
> is desirable.

I saw your upstream comment, and it took a quick look at it.  On the
face of it, I couldn't see where checking that the parent exists on
the insert of a child would be broken by the existence of other
orphan children, nor could I see where checking for the absence of
children on the delete of a parent would be broken by orphan children
not related to the parent.  With other things on my plate I didn't
have time to do a rigorous check, but it was enough to make me wonder
what you think depends on existing consistency or what could break. 
Even a vague hint of what sort of thing you think might go wrong
might help people find problem code, if it actually exists.

Now, I understand that a broken index, like one based on a function
declared immutable which really isn't, could cause problems, but that
seems orthogonal.

-Kevin

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Bug? Unexpected argument handling in pl-python variadic argument function

2011-01-23 Thread Nate C

Unexpected argument handling in pl/python variadic argument function

create or replace function variadic_sql
(template text, variadic args text[], out text)
language sql as
$$
select $1 || '  --  ' || $2::text
$$;

create or replace function variadic_python
(template text, variadic args text[], out text)
language plpythonu as
$$
return template + '  --  ' + str(args)
$$;


-- expected
select variadic_sql('{foo}{bar}', '1', '2');
variadic_sql

 {foo}{bar}  --  {1,2}


-- first scalar arg also in the variadic args
select variadic_python('{foo}{bar}', '1', '2');


   variadic_python
--
 {foo}{bar}  --  ['{foo}{bar}', ['1', '2']]


select version();
 PostgreSQL 9.0.1 on i686-pc-linux-gnu, compiled by GCC
i686-pc-linux-gnu-gcc (Gentoo 4.4.2 p1.0) 4.4.2, 32-bit
(1 row)


I could not find very much documentation and only this on the lists:

from Jan Urbański on his planned improvements for pl/python:
http://archives.postgresql.org/pgsql-hackers/2010-12/msg00551.php

> * variadic argument handling (is this possible for a non-plpgsql pl?)

Does this mean this is already a recognized flaw or it was unknown at
the time if the feature was implemented?  I would definitely would not
expect the argument to duplicated.  I know there is big patch for
pl/python being reviewed right now.  Perhaps this is being fixed? It
would be wonderful for plpython to support complex arguments
gracefully.



-- 
Thanks,
Nate Carson

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Bug in pg_describe_object, patch v2

On Sun, Jan 23, 2011 at 4:24 PM, Joel Jacobson  wrote:
> In the aftermath, I realized I was almost about to feel a bit ashamed
> about the fact my original forum post probably gave birth to the most
> long lived discussion in the history of PostgreSQL.

I think you'd need another order of magnitude to achieve that exalted
position.  :-)

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] wildcard search support for pg_trgm

2011-01-23 Thread Jan Urbański

Hi,

I tested the patch from
http://archives.postgresql.org/message-id/aanlktikvxx6_ajzb52ona7mbzijcpdqszomcd-3u1...@mail.gmail.com
which adds GIN and GIST index support for wildcard LIKE queries using
pg_trgm.

The patch is a context diff that applies cleanly. Regression test work
after applying it, but they only exercise the similarity() function, so
the new functionality is not covered by them.

The patch seems to work as advised, I tried a few searches and it does
indeed use the gin or gist index to implement '%foo%' searches. I tried
to do some tricky queries and it worked for all of them..

I see two issues with this patch. First of them is the resulting index
size. I created a table with 5 copies of
/usr/share/dict/american-english in it and a gin index on it, using
gin_trgm_ops. The results were:

* relation size: 18MB
* index size: 109 MB

while without the patch the GIN index was 43 MB. I'm not really sure
*why* this happens, as it's not obvious from reading the patch what
exactly is this extra data that gets stored in the index, making it more
than double its size.

That leads me to the second issue. The pg_trgm code is already woefully
uncommented, and after spending quite some time reading it back and
forth I have to admit that I don't really understand what the code does
in the first place, and so I don't understand what does that patch
change. I read all the changes in detail and I could't find any obvious
mistakes like reading over array boundaries or dereferencing
uninitialized pointers, but I can't tell if the patch is correct
semantically. All test cases I threw at it work, though.

I'm not sure if the committer with better knowledge of pg_trgm would be
able to do a better job than me. After a few days digging in that code I
simply give up.

This patch changes the names and signatures of some support functions
for GIN, and I'm not sure how that affects binary compatibility and
pg_upgrade. I tried to create an index with the vanilla source, and then
recompile pg_trgm and reindex the table, but it still was not using the
index. I think it's because it's missing entries in the catalogs about
the index supporting the like strategy. How should this be handled?

I'm going to mark the patch as Waiting on Author, because of the index
size issue (though it might be OK and expected that the index size will
grow so much, I just don't know). As for the comments, or lack of them,
I declary myself incompetent to thoroughly verify that the patch works.
I think it should have at least the added parts commented enough to
match the project's standard.

Sorry for taking so long to review this,

Cheers,
Jan

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED

On Sun, 2011-01-23 at 16:13 -0500, Tom Lane wrote:
> Simon Riggs  writes:
> > You can add an FK without an initial check, but the FK is enforced for
> > all further DML changes.
> 
> I seem to recall pointing out upthread that the FK check triggers are
> designed on the assumption that the constraint does hold currently.
> Has any analysis been done on exactly how badly they'll fail when it
> doesn't hold?  I remain unconvinced that this behavior is desirable.

If you mean RESTRICT relationships, then yes.

I haven't foreseen other problems myself. What other ideas or risks
would you like me to confirm or deny for you? 

-- 
 Simon Riggs   http://www.2ndQuadrant.com/books/
 PostgreSQL Development, 24x7 Support, Training and Services
 


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] One Role, Two Passwords

2011-01-23 Thread Daniel Farina

On Thu, Jan 20, 2011 at 6:19 PM, Stephen Frost  wrote:
> Errr, well, ok, this is curious.
>
> gis=> alter user sfrost set role gis;
> ALTER ROLE
> gis=> ^D\q
> beren:/home/sfrost> psql --cluster 8.4/main -d gis
> psql (8.4.5)
> Type "help" for help.
>
> gis=> show role;
>  role
> --
>  gis

So far, I think this does exactly what you think it would...

This is how I think a mostly-transparent one-role-two-password (ish)
system would look like using this property, using a group, as Tom
suggested:

-- Note: This role does not have LOGIN set
CREATE ROLE public_facing_name;

-- The first set of credentials
CREATE ROLE first_arbitrary_name IN ROLE public_facing_name LOGIN
PASSWORD 'first_secret';
ALTER ROLE first_arbitrary_name SET ROLE public_facing_name;

-- The second set of credentials
CREATE ROLE second_arbitrary_string IN ROLE public_facing_neme LOGIN
PASSWORD 'second_secret';
ALTER ROLE second_arbitrary_name SET ROLE public_facing_name;

When one logs in as one_arbitrary_name or second_arbitrary_name, all
CREATE statements -- and indeed, all privilege checks -- will take
place against public_facing_name. No objects should ever get created
under the roles "first_arbitrary_name" or "second_arbitrary_name," and
no ownership ever assigned to them, unless the client runs SET ROLE to
un-do what was done.  This would be annoying (when dropping sets of
credentials, or when ownership-specific privileges apply to one set of
credentials but not the other) but may not occur much at large.

Thoughts?

--
fdr

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Bug in pg_describe_object, patch v2

2011-01-23 Thread Joel Jacobson

2011/1/23 Dimitri Fontaine :
> Tom Lane  writes:
>>   But anyway, this patch has now officially
>> been discussed to death.
>
> +1 :)

+∞ :)

In the aftermath, I realized I was almost about to feel a bit ashamed
about the fact my original forum post probably gave birth to the most
long lived discussion in the history of PostgreSQL. Having realized
this, I realized a secondly even more important fact, namely the
importance of details, making the whole difference between a sloppy
software project and a highly successful project with the ambition of
achieving perfection in every little detail. I'm proud we can conclude
ProstgreSQL is apparently a project of the second category.

-- 
Best regards,

Joel Jacobson
Glue Finance

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pg_dump directory archive format / parallel pg_dump

2011-01-23 Thread Heikki Linnakangas


On 21.01.2011 19:11, Euler Taveira de Oliveira wrote:

Em 21-01-2011 12:47, Andrew Dunstan escreveu:

Maybe we could change the hint to say "--file=DESTINATION" or
"--file=FILENAME|DIRNAME" ?


... "--file=OUTPUT" or "--file=OUTPUTNAME".


Ok, works for me.

I've committed this patch now, with a whole bunch of further fixes.

--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED

Simon Riggs  writes:
> You can add an FK without an initial check, but the FK is enforced for
> all further DML changes.

I seem to recall pointing out upthread that the FK check triggers are
designed on the assumption that the constraint does hold currently.
Has any analysis been done on exactly how badly they'll fail when it
doesn't hold?  I remain unconvinced that this behavior is desirable.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED

On Tue, 2010-12-14 at 11:24 -0500, Chris Browne wrote:
> t...@sss.pgh.pa.us (Tom Lane) writes:
> > Robert Haas  writes:
> >> ...  On the
> >> other hand, there's clearly also a use case for this behavior.  If a
> >> bulk load of prevalidated data forces an expensive revalidation of
> >> constraints that are already known to hold, there's a real chance the
> >> DBA will be backed into a corner where he simply has no choice but to
> >> not use foreign keys, even though he might really want to validate the
> >> foreign-key relationships on a going-forward basis.
> >
> > There may well be a case to be made for doing this on grounds of
> > practical usefulness.  I'm just voicing extreme skepticism that it can
> > be supported by reference to the standard.
> >
> > Personally I'd prefer to see us look into whether we couldn't arrange
> > for low-impact establishment of a verified FK relationship, analogous to
> > CREATE INDEX CONCURRENTLY.  We don't let people just arbitrarily claim
> > that a uniqueness condition exists, and ISTM that if we can handle that
> > case we probably ought to be able to handle FK checking similarly.
> 
> I can point to a use case that has proven useful...
> 
> Slony-I deactivates indices during the subscription process, because it
> is enormously more efficient to load the data into the tables
> sans-indices, and then re-index afterwards.
> 
> The same would apply for FK constraints.
> 
> I observe that the deactivation of indices is the sole remaining feature
> in Slony-I that still requires catalog access in a "corruptive" sense.
> (With the caveat that this corruption is now only a temporary one; the
> indexes are returned into play before the subscription process
> finishes.)
> 
> That would be eliminated by adding in:
>   "ALTER TABLE ... DISABLE INDEX ..."
>   "ALTER TABLE ... ENABLE INDEX ..."
> 
> For similar to apply to FK constraints would involve similar logic.

I just wanted to point out that the patch submitted here does not allow
what is requested here for FKs (nor indexes).

You can add an FK without an initial check, but the FK is enforced for
all further DML changes. You can then later validate the FK. So that
running these commands

ALTER TABLE foo ADD FOREIGN KEY ... NOT VALID;
ALTER TABLE foo VALIDATE CONSTRAINT ...;

is roughly equivalent to the concept of

ALTER TABLE foo ADD FOREIGN KEY ... CONCURRENTLY;

There is no command that makes the FK "NOT ENFORCED", so you can't turn
it off then back on again as was requested above.

-- 
 Simon Riggs   http://www.2ndQuadrant.com/books/
 PostgreSQL Development, 24x7 Support, Training and Services
 


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Bug in pg_describe_object, patch v2

2011-01-23 Thread Dimitri Fontaine

Tom Lane  writes:
>   But anyway, this patch has now officially
> been discussed to death.

+1 :)

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] REVIEW: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED

On Sun, 2011-01-23 at 14:45 -0500, Tom Lane wrote:
> Simon Riggs  writes:
> > On Sun, 2011-01-23 at 20:33 +0200, Marko Tiikkaja wrote:
> >> \d table now only shows that there's a FOREIGN KEY, which might lead the 
> >> user to think that there should not be any values that don't exist in 
> >> the referenced table.
> 
> > Neither \d nor \di shows invalid indexes.
> 
> Even if that were true, it's a poor analogy, since a disabled foreign
> key has visible *semantic* impact, whereas a disabled index doesn't.

Sure. My agreement to add something appears to have crossed with your
comments.

I'd appreciate you reviewing the parser aspects of the patch. $TITLE no
longer reflects the syntax.

-- 
 Simon Riggs   http://www.2ndQuadrant.com/books/
 PostgreSQL Development, 24x7 Support, Training and Services
 


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] REVIEW: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED

Simon Riggs  writes:
> On Sun, 2011-01-23 at 20:33 +0200, Marko Tiikkaja wrote:
>> \d table now only shows that there's a FOREIGN KEY, which might lead the 
>> user to think that there should not be any values that don't exist in 
>> the referenced table.

> Neither \d nor \di shows invalid indexes.

Even if that were true, it's a poor analogy, since a disabled foreign
key has visible *semantic* impact, whereas a disabled index doesn't.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Bug in pg_describe_object, patch v2

Robert Haas  writes:
> On Sun, Jan 23, 2011 at 11:50 AM, Tom Lane  wrote:
>> So I guess I'm coming around to the idea that we want something not too
>> much bigger than Andreas' original patch, but applying to both amop and
>> amproc, and putting the operator/function description at the end.

> That's fine with me.

OK, committed that way.

> I think the principal argument for failing to
> remove it entirely is that we've traditionally had it there, but IMHO
> moving in the direction of treating them as separate objects is much
> more clear and an altogether better approach.

I think there's a usability argument in addition to just plain "we
always did it that way".  But anyway, this patch has now officially
been discussed to death.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] REVIEW: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED

On Sun, 2011-01-23 at 20:56 +0200, Marko Tiikkaja wrote:
> On 1/23/2011 8:43 PM, Simon Riggs wrote:
> > On Sun, 2011-01-23 at 20:33 +0200, Marko Tiikkaja wrote:
> >> On 1/23/2011 8:23 PM, Simon Riggs wrote:
> >>> On Sun, 2011-01-23 at 19:50 +0200, Marko Tiikkaja wrote:
>  Another problem I found is that psql doesn't indicate in any way that a
>  FOREIGN KEY constraint is not validated yet.
> >>>
> >>> Should it?
> >>> What command do you think needs changing?
> >>
> >> \d table now only shows that there's a FOREIGN KEY, which might lead the
> >> user to think that there should not be any values that don't exist in
> >> the referenced table.
> >
> > Neither \d nor \di shows invalid indexes.
> 
> What exactly are you referring to?  An index with indisvalid=false looks 
> like this in my psql:
> 
> "fooindex" btree (a) INVALID
> 
> And even if it didn't, I don't think we should be adding more 
> deficiencies to psql.

OK, thanks, I wasn't aware of that.

I'll add something similar for FKs.

-- 
 Simon Riggs   http://www.2ndQuadrant.com/books/
 PostgreSQL Development, 24x7 Support, Training and Services
 


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] REVIEW: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED

2011-01-23 Thread Marko Tiikkaja


On 1/23/2011 8:43 PM, Simon Riggs wrote:

On Sun, 2011-01-23 at 20:33 +0200, Marko Tiikkaja wrote:

On 1/23/2011 8:23 PM, Simon Riggs wrote:

On Sun, 2011-01-23 at 19:50 +0200, Marko Tiikkaja wrote:

Another problem I found is that psql doesn't indicate in any way that a
FOREIGN KEY constraint is not validated yet.


Should it?
What command do you think needs changing?


\d table now only shows that there's a FOREIGN KEY, which might lead the
user to think that there should not be any values that don't exist in
the referenced table.


Neither \d nor \di shows invalid indexes.


What exactly are you referring to?  An index with indisvalid=false looks 
like this in my psql:


"fooindex" btree (a) INVALID

And even if it didn't, I don't think we should be adding more 
deficiencies to psql.



Should we add validation for FKs when it is not there for indexes?
My feeling was no.

Desirable for both? Yes, but not as part of this patch.


There is no option to invoke this yet from pg_restore, which seems
likely to top the list of priorities. Would you agree?


I don't understand what you mean with this.  Could you be a bit more
elaborate?


The purpose of this patch is performance. pg_restore will be faster if
it uses this new feature, so I expect to add an option to reload data
without validating FKs.


Ah.  Right, that would make sense.


Regards,
Marko Tiikkaja

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [COMMITTERS] pgsql: Only show pg_stat_replication details to superusers

On Sun, Jan 23, 2011 at 19:27, Simon Riggs  wrote:
> On Sun, 2011-01-23 at 16:28 +, Magnus Hagander wrote:
>
>> Only show pg_stat_replication details to superusers
>
> What happens to those with REPLICATION privilege? Denied access?

Correct, same as those without it - only superuser is enough.

For rationale, see the original thread discussing the patch :)


-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] REVIEW: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED

On Sun, 2011-01-23 at 20:33 +0200, Marko Tiikkaja wrote:
> On 1/23/2011 8:23 PM, Simon Riggs wrote:
> > On Sun, 2011-01-23 at 19:50 +0200, Marko Tiikkaja wrote:
> >> Another problem I found is that psql doesn't indicate in any way that a
> >> FOREIGN KEY constraint is not validated yet.
> >
> > Should it?
> > What command do you think needs changing?
> 
> \d table now only shows that there's a FOREIGN KEY, which might lead the 
> user to think that there should not be any values that don't exist in 
> the referenced table.

Neither \d nor \di shows invalid indexes.

Should we add validation for FKs when it is not there for indexes?
My feeling was no.

Desirable for both? Yes, but not as part of this patch.

> > There is no option to invoke this yet from pg_restore, which seems
> > likely to top the list of priorities. Would you agree?
> 
> I don't understand what you mean with this.  Could you be a bit more 
> elaborate?

The purpose of this patch is performance. pg_restore will be faster if
it uses this new feature, so I expect to add an option to reload data
without validating FKs.

-- 
 Simon Riggs   http://www.2ndQuadrant.com/books/
 PostgreSQL Development, 24x7 Support, Training and Services
 


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] REVIEW: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED

2011-01-23 Thread Marko Tiikkaja


On 1/23/2011 8:23 PM, Simon Riggs wrote:

On Sun, 2011-01-23 at 19:50 +0200, Marko Tiikkaja wrote:

Another problem I found is that psql doesn't indicate in any way that a
FOREIGN KEY constraint is not validated yet.


Should it?
What command do you think needs changing?


\d table now only shows that there's a FOREIGN KEY, which might lead the 
user to think that there should not be any values that don't exist in 
the referenced table.



I also think that having the function for getting a list of values that
violate the constraint would be helpful.  Any particular reason why you
decided to omit it from this patch?


Yes, the consensus was that DDL was required, not a function. Function
was my preferred approach originally.


While I do agree that the DDL command should be the preferred way to 
validate the constraint, I think the function adds a significant value 
when the validation does not succeed.



That now appears to be an additional request from a couple of people. At
present, its easy enough to write the SQL statement yourself, so that's
non-essential, and maybe/likely won't make this release (not sure,
depends upon how other aspects go).


I understand.


There is no option to invoke this yet from pg_restore, which seems
likely to top the list of priorities. Would you agree?


I don't understand what you mean with this.  Could you be a bit more 
elaborate?



Regards,
Marko Tiikkaja

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Re: [COMMITTERS] pgsql: Only show pg_stat_replication details to superusers

On Sun, 2011-01-23 at 16:28 +, Magnus Hagander wrote:

> Only show pg_stat_replication details to superusers

What happens to those with REPLICATION privilege? Denied access?

-- 
 Simon Riggs   http://www.2ndQuadrant.com/books/
 PostgreSQL Development, 24x7 Support, Training and Services
 


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] REVIEW: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED

On Sun, 2011-01-23 at 19:50 +0200, Marko Tiikkaja wrote:
> Hi Simon,
> 
> On 1/14/2011 1:15 PM, Simon Riggs wrote:
> > Patch to implement the proposed feature attached, for CFJan2011.
> 
> Overall, I think the patch looks good

Thanks for the review.

> , but I found some problems with 
> it.  In tablecmds.c you have:
> 
> +   if (found && con->contype == CONSTR_FOREIGN && !con->convalidated)
> 
> which I don't think is correct, and my tests seem to agree; the actual 
> validation doesn't happen at all.  Changing that to CONSTRAINT_FOREIGN 
> makes the validation part work, but then I get:
> 
> ERROR:  cache lookup failed for constraint 16419
> 
> when trying to drop the table and the regression tests fail because of 
> this.  Also having a regression test where the validation fails seems 
> like a good idea.

Thanks. Will fix.

> Another problem I found is that psql doesn't indicate in any way that a 
> FOREIGN KEY constraint is not validated yet.

Should it?
What command do you think needs changing?

> I also think that having the function for getting a list of values that 
> violate the constraint would be helpful.  Any particular reason why you 
> decided to omit it from this patch?

Yes, the consensus was that DDL was required, not a function. Function
was my preferred approach originally.

That now appears to be an additional request from a couple of people. At
present, its easy enough to write the SQL statement yourself, so that's
non-essential, and maybe/likely won't make this release (not sure,
depends upon how other aspects go).

There is no option to invoke this yet from pg_restore, which seems
likely to top the list of priorities. Would you agree?

-- 
 Simon Riggs   http://www.2ndQuadrant.com/books/
 PostgreSQL Development, 24x7 Support, Training and Services
 


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] REVIEW: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED

2011-01-23 Thread Marko Tiikkaja


Hi Simon,

On 1/14/2011 1:15 PM, Simon Riggs wrote:

Patch to implement the proposed feature attached, for CFJan2011.


Overall, I think the patch looks good, but I found some problems with 
it.  In tablecmds.c you have:


+   if (found && con->contype == CONSTR_FOREIGN && !con->convalidated)

which I don't think is correct, and my tests seem to agree; the actual 
validation doesn't happen at all.  Changing that to CONSTRAINT_FOREIGN 
makes the validation part work, but then I get:


ERROR:  cache lookup failed for constraint 16419

when trying to drop the table and the regression tests fail because of 
this.  Also having a regression test where the validation fails seems 
like a good idea.


Another problem I found is that psql doesn't indicate in any way that a 
FOREIGN KEY constraint is not validated yet.


I also think that having the function for getting a list of values that 
violate the constraint would be helpful.  Any particular reason why you 
decided to omit it from this patch?



Regards,
Marko Tiikkaja

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Bug in pg_describe_object, patch v2

On Sun, Jan 23, 2011 at 11:50 AM, Tom Lane  wrote:
> And yet ... and yet ... if you adopt the position that what we're going
> to print is "amproc item: referenced procedure", then it's not entirely
> clear why the amproc item description shouldn't be complete. The
> argument that it's redundant with the procedure description gets a lot
> weaker as soon as you look at them as two separate items.  Ditto amop.
> And having to add a lot of otherwise-useless code to suppress the
> redundancy surely isn't very attractive.

I couldn't agree more.  Sorry if I didn't explain that concern clearly
enough upthread.

> So I guess I'm coming around to the idea that we want something not too
> much bigger than Andreas' original patch, but applying to both amop and
> amproc, and putting the operator/function description at the end.

That's fine with me.  I think the principal argument for failing to
remove it entirely is that we've traditionally had it there, but IMHO
moving in the direction of treating them as separate objects is much
more clear and an altogether better approach.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Perl 5.12 complains about ecpg parser-hacking scripts

2011-01-23 Thread kris

On 23 January 2011 14:28, Kris Shannon  wrote:
> On 23 January 2011 13:14, Andrew Dunstan  wrote:
>> But there are quite a few perlheads around. ISTR Matt Trout was muttering
>> about these scripts on IRC recently.
>
> A quick cleanup of the check_rules.pl...
>
> It's a starting point at least.
>

And I should have at least tried to run this before I submitted... :(
New minimal tested submission momentarily.

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Perl 5.12 complains about ecpg parser-hacking scripts

2011-01-23 Thread kris

On 24 January 2011 03:06, Andrew Dunstan  wrote:
> It's doing the right thing. But it's really spaghetti code, generated by
> a2p. Matt was just (rightly) offended by the $[ setting, IIRC.
>
> The point is that it's close to being totally unmaintainable.
>
> But if you think you can remedy it without rewriting it, go for it.
>
> I think minimum requirements would be:
>
>   * avoid setting $[
>   * use strict;
>   * comments saying what it's actually doing
>
>
> We want to be in a situation where of it ever does break because of some
> external change, we're not left having to wade through the crap to find out
> how to fix it.
>
> cheers
>
> andrew
>

Well here's an absolutely minimal patch to remove the $[ assignments
and fix up the array accesses.
I have tested that parse.pl produces identical output for both HEAD
and the 65 commits which touch ecpg.*
or gram.y since the introduction on check_rules.pl

git log 81a82a13^..HEAD -- src/backend/parser/gram.y
src/interfaces/ecpg/preproc/{ecpg.??*,*.pl}

I've also tested that the new check_rules.pl dies when I add an extra
unused rule to ecpg.addons.

I'll try and make a proper rewrite sometime this week.

What is the minimal perl version that we are requiring these days?

ecpg_preproc_minimal_perl_cleanup.patch
Description: Binary data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Perl 5.12 complains about ecpg parser-hacking scripts

Kris Shannon  writes:
> What is the minimal perl version that we are requiring these days?

5.8 according to configure.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Perl 5.12 complains about ecpg parser-hacking scripts

Andy Colson  writes:
> Is there anyway to make bison/yacc/gcc/etc spit out the rule names?

bison -v produces a debug output file that includes nicely cleaned-up
versions of all the rules.  But it includes a lot of other stuff too,
and I'm not at all sure that the file format is stable across bison
versions, so maybe depending on that isn't a hot idea.

> I'm not sure rule name is the proper words.  In gram.y we have:

"Production" is the standard technical name, but on the other hand the
bison documentation seems to consistently use the word "rule", so
there's probably nothing wrong with doing so here too.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] sepgsql contrib module

Magnus Hagander  writes:
> On Sun, Jan 23, 2011 at 03:19, Robert Haas  wrote:
>> That's pretty horrendous.  Tom/Bruce, any ideas?

> I saw some similar things earlier, and it turned out to be two
> different reasons in two different cases. In one case, it was because
> I was using GNU indent, even though I thought I was using the one
> that's on our ftp. But it does give a warning in that case, you just
> have to actually *read* the warning. In the other case it was really
> weird - when my wrapper script (that called pgindent with path
> specification and such) executing using dash (the default /bin/sh on
> Ubuntu), it did weird things - but when I explicitly executed the
> wrapper script with /bin/bash, it worked - even though pgindent itself
> is still using /bin/sh.

Hm, but then the inner /bin/sh is really dash no?  Maybe the outer
invocation is setting environment variables or something to change the
behavior of the inner invocation.  That would be pretty broken, but IME
most bash substitutes are pretty broken.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Perl 5.12 complains about ecpg parser-hacking scripts

2011-01-23 Thread Andy Colson


On 01/23/2011 10:06 AM, Andrew Dunstan wrote:



On 01/23/2011 10:16 AM, Andy Colson wrote:

On 01/23/2011 08:29 AM, Andy Colson wrote:

On 01/22/2011 09:28 PM, k...@shannon.id.au wrote:

On 23 January 2011 13:14, Andrew Dunstan wrote:

But there are quite a few perlheads around. ISTR Matt Trout was muttering
about these scripts on IRC recently.


Ok, so I've figured out what its purpose is.

Are there other problems with this script? Does it not pull out the rule names 
correct all the time or something? What problem was Matt having with it?

I think rewriting from scratch is overkill, unless this script is just failing. 
The code to pull the rule names out is a bit complex, and it seems to work, so 
I'd rather not touch it.

Are there other things you wished this script did? (reports, counts, etc)





It's doing the right thing. But it's really spaghetti code, generated by a2p. 
Matt was just (rightly) offended by the $[ setting, IIRC.

The point is that it's close to being totally unmaintainable.

But if you think you can remedy it without rewriting it, go for it.

I think minimum requirements would be:

* avoid setting $[
* use strict;
* comments saying what it's actually doing


We want to be in a situation where of it ever does break because of some 
external change, we're not left having to wade through the crap to find out how 
to fix it.

cheers

andrew


** OOPS, forenote: I only noticed check_rules.pl.  That's the only file I 
looked at.  I'll go look at parse.pl right now.  Below refers to check_rules.pl 
only.

I can comment the code.  $[ can safely be removed (from check_rules.pl) because 
we are not even using arrays.

I disagree (check_rules.pl) is not spaghetti code.  There are two loops, one 
thru gram.y to pick out the rule names, and one through ecpg.addons to make 
sure they are in use.

Unmaintainable is another story.  Parsing gram.y for rule names, then combining 
them to make up the same name in ecpg.addons is a little complex.  But then I 
think it would be a little complex in any language.  A little change to the 
syntax/layout of either file and it could go bad, but you'd have that same 
problem with any other language too.

Is there anyway to make bison/yacc/gcc/etc spit out the rule names?

I'm not sure rule name is the proper words.  In gram.y we have:

stmt :
AlterDatabaseStmt
| AlterDatabaseSetStmt


We pull out and create:

stmtAlterDatabaseStmt
and
stmtAlterDatabaseSetStmt


-Andy

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] ALTER TYPE 2: skip already-provable no-work rewrites

Robert Haas  writes:
> On Sun, Jan 9, 2011 at 5:01 PM, Noah Misch  wrote:
>> As unintended fallout, it's no longer an error to add oids or a column with a
>> default value to a table whose rowtype is used in columns elsewhere.  This 
>> seems
>> best.  Defaults on the origin table do not even apply to new inserts into 
>> such a
>> column, and the rowtype does not gain an OID column via its table.

> I think this should be split into two patches (we can discuss both on
> this thread, no need to start any new ones), one that implements just
> the above improvement and another that accomplishes the main purpose
> of the patch.

I haven't been paying much attention to this thread, but I happened to
read the above, and quite frankly it scares the cr*p out of me.  I don't
believe that Noah even begins to be qualified to understand the
implications of adding/removing an OID column, and I clearly remember
the non-obvious bugs we've had in the past from that.  Before this goes
in I want to see a convincing explanation (not an unsupported assertion)
why this isn't going to re-introduce those old bugs.

I'm also pretty unclear on why it's a good idea to let uses of a rowtype
be different from the table on which it's allegedly based.  To the
extent that the current behavior allows that, isn't that a bug rather
than a feature we should extend?

>> # The fact that ALTER TYPE requires rewriting the whole table is
>> sometimes an advantage, because the rewriting process
>> # eliminates any dead space in the table.

> I'm not sure what we can recommend here instead.

New-style VACUUM FULL.  I don't think that a patch that makes it harder
to use ALTER TABLE this way is a problem in itself, now that we've got
that.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Bug in pg_describe_object, patch v2

I wrote:
> Robert Haas  writes:
>> We're trying to represent the pg_amproc entry here, and including a
>> bunch of details of the pg_proc entry to which it happens to point
>> seems almost better to be confusing the issue.

> Yeah, that occurred to me too.  However, the CREATE OPERATOR CLASS
> syntax doesn't really draw a distinction between the referenced
> function/operator and its reference in the opclass, and I'm not sure
> users do either.  So I don't want to give up the details of the function
> or operator.  But sticking them at the end after a colon might make it
> clearer that the func/operator is referenced by the amproc or amop
> entry, but is not the same thing.

And yet ... and yet ... if you adopt the position that what we're going
to print is "amproc item: referenced procedure", then it's not entirely
clear why the amproc item description shouldn't be complete.  The
argument that it's redundant with the procedure description gets a lot
weaker as soon as you look at them as two separate items.  Ditto amop.
And having to add a lot of otherwise-useless code to suppress the
redundancy surely isn't very attractive.

So I guess I'm coming around to the idea that we want something not too
much bigger than Andreas' original patch, but applying to both amop and
amproc, and putting the operator/function description at the end.

Comments?

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Perl 5.12 complains about ecpg parser-hacking scripts

2011-01-23 Thread Michael Meskes

On Sun, Jan 23, 2011 at 09:16:33AM -0600, Andy Colson wrote:
> Are there other problems with this script?  Does it not pull out the rule 
> names correct all the time or something?  What problem was Matt having with 
> it?

No, afaict it works correctly but throws some warnings.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at googlemail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pg_stat_replication security

On Mon, Jan 17, 2011 at 13:14, Magnus Hagander  wrote:
> On Mon, Jan 17, 2011 at 12:11, Itagaki Takahiro
>  wrote:
>> On Mon, Jan 17, 2011 at 19:51, Magnus Hagander  wrote:
>>> Here's a patch that limits it to superuser only. We can't easily match
>>> it to the user of the session given the way the walsender data is
>>> returned - it doesn't contain the user information. But limiting it to
>>> superuser only seems perfectly reasonable and in line with the
>>> encouragement not to use the replication user for login.
>>>
>>> Objections?
>>
>> It hides all fields in pg_stat_wal_senders(). Instead, can we just
>> revoke usage of the function and view?  Or, do we have some plans
>> to add fields which normal users can see?
>
> Yes, for consistency with pg_stat_activity. We let all users see which
> other sessions are there, but not what they're doing - seems
> reasonable to have the same definitions for replication sessions as
> other sessions.

Committed.

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Perl 5.12 complains about ecpg parser-hacking scripts

2011-01-23 Thread Andrew Dunstan




On 01/23/2011 10:16 AM, Andy Colson wrote:

On 01/23/2011 08:29 AM, Andy Colson wrote:

On 01/22/2011 09:28 PM, k...@shannon.id.au wrote:

On 23 January 2011 13:14, Andrew Dunstan wrote:
But there are quite a few perlheads around. ISTR Matt Trout was 
muttering

about these scripts on IRC recently.


Ok, so I've figured out what its purpose is.

Are there other problems with this script?  Does it not pull out the 
rule names correct all the time or something?  What problem was Matt 
having with it?


I think rewriting from scratch is overkill, unless this script is just 
failing.  The code to pull the rule names out is a bit complex, and it 
seems to work, so I'd rather not touch it.


Are there other things you wished this script did?  (reports, counts, 
etc)






It's doing the right thing. But it's really spaghetti code, generated by 
a2p. Matt was just (rightly) offended by the $[ setting, IIRC.


The point is that it's close to being totally unmaintainable.

But if you think you can remedy it without rewriting it, go for it.

I think minimum requirements would be:

   * avoid setting $[
   * use strict;
   * comments saying what it's actually doing


We want to be in a situation where of it ever does break because of some 
external change, we're not left having to wade through the crap to find 
out how to fix it.


cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Perl 5.12 complains about ecpg parser-hacking scripts

2011-01-23 Thread Andy Colson


On 01/23/2011 08:29 AM, Andy Colson wrote:

On 01/22/2011 09:28 PM, k...@shannon.id.au wrote:

On 23 January 2011 13:14, Andrew Dunstan wrote:

But there are quite a few perlheads around. ISTR Matt Trout was muttering
about these scripts on IRC recently.


Ok, so I've figured out what its purpose is.

Are there other problems with this script?  Does it not pull out the rule names 
correct all the time or something?  What problem was Matt having with it?

I think rewriting from scratch is overkill, unless this script is just failing. 
 The code to pull the rule names out is a bit complex, and it seems to work, so 
I'd rather not touch it.

Are there other things you wished this script did?  (reports, counts, etc)

-Andy

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SSPI client authentication in non-Windows builds

2011-01-23 Thread Christian Ullrich


* Christian Ullrich wrote:


Magnus Hagander wrote:



On Mon, Jan 3, 2011 at 14:11, Christian Ullrich
wrote:



This change has been tested and works correctly on FreeBSD 8.1, using
the Kerberos and GSSAPI libraries from Heimdal 1.4. The server is
running PostgreSQL 9.0.2 on Windows 2008.



Does this require some certain minimum version of the kerberos
libraries? Do you know if it works with just Heimdal or both Heimdal
and MIT?



it works with anything but the configuration I mentioned. I will do some
more testing this week, but I'm limited in the number of combinations I
can try; some randomly chosen Linux distributions with whatever Kerberos
they ship and the Heimdal from the FreeBSD 8 base system instead of the
port (if I can get PostgreSQL to build with that) against Windows 2003
and 2008 is probably going to be all I can offer. Expect a report early
next week.


This is what I tested this week. If there are any additional questions, 
please let me know.



Clients tested
--

1 FreeBSD 8.1 (x86), Heimdal 1.4 (released Sep 2010)
2 Gentoo Linux (x86_64) 20110113, Heimdal 1.3.3 (released May 2010)
3 Gentoo Linux (x86_64) 20110113, MIT 1.9 (released Dec 2010)
4 Gentoo Linux (x86_64) 20110113, MIT 1.8.3 (released Aug 2010)
5 Ubuntu Linux (x86) 10.10, MIT 1.8.1 (released Apr 2010)
6 FreeBSD 7.0 (x86), Heimdal 0.7 (released Jun 2005)
7 Debian Linux (x86) 5.0.7, MIT 1.4 (released Jan 2005)
8 Debian Linux (x86) 5.0.7, Heimdal 0.7.2 (released Feb 2006)

Notes:

My approach in building PostgreSQL on the clients was to first get it to 
build without the patch, then add the patch, do a minimal rebuild 
("make") and test with databases configured for "md5" and "sspi" 
authentication.


I also tried GNU shishi as a third Kerberos implementation, but could 
not get it to even attempt to get a TGT.


2, 3, 4: These were the only Kerberos implementations available
 in Portage, obviously very recent ones.

6:   Heimdal 0.7 was the oldest release I could get to build
 on this platform, and getting PostgreSQL to link against
 it required some work.

7:   MIT 1.4 is the first release that will build with gcc 4,
 while the first release that PostgreSQL might possibly
 compile with is 1.3. Everything before that does not
 have a sufficient GSSAPI. For the GCC issue see GCC bug
 #18799.

8:   There was an interesting build issue in this configuration.
 Linux glibc does not include strlcpy(), which is why both
 libpgport and Heimdal's libroken have their own versions.
 What happens is that PostgreSQL's configure, after
 correctly determining that there is no declaration of
 strlcpy() in the system headers, nevertheless detects
 libroken's implementation and excludes it from libpgport.
 Later, (at least) ecpg and initdb fail to link because it
 is not there. I could not figure out how to force it to
 be included in libpgport, so I had to use libroken instead.

Servers tested
--

A Windows Server 2008 (x86_64), PostgreSQL 9.0.2 (x86_64)
B Windows Server 2008R2 (x86_64), PostgreSQL 8.4.4 (x86)
C Windows Server 2003R2 (x86), PostgreSQL 9.0.2 (x86)

Notes:

A:This is the (production) installation I mentioned originally.

B, C: These are dedicatedldd testing installations.


Server configuration procedure
--

- Installed operating system
- Joined to domain
- Installed PostgreSQL
- Stopped service
- Created service account in domain, added SPNs using ADSIEdit

  I used a "managed service account" for the 2008R2 server, which I then
  installed on that server. Postgres on the 2003R2 server is using a
  standard user account.

- Changed permissions on data directory
- Changed service logon
- Started service


Combinations tested successfully


1   2   3   4   5   6   7   8

A   X

B   X   X   X   X   X   X

C   X   X   X


Combinations tested unsuccessfully
--

1   2   3   4   5   6   7   8

A

B

C


Conclusion
--

There is no detectable risk of SSPI-via-GSS authentication failure due 
to interoperability problems between the client's GSSAPI and the 
server's SSPI, no matter the versions involved. The only potential 
exception is with a Windows 2000 server, which I did not have access to 
and consequently did not test.


A number of pitfalls can hamper building PostgreSQL, especially with 
older Kerberos implementations. These, however, will equally affect 
builds that are intended to use only "traditional" GSSAPI authentication.


I am not sure what I may have done wrong in the case of client 8, which 
was a Debian system installed using the minimal CD. Maybe I was missing 
some package or other. Given that this was on Debian, it would surprise 
me if it was a genuine bug in configure.


--
Christian

--
Sent via pgsql-hackers mail

[HACKERS] 答复: [HACKERS] Is there a way to build PostgreSQL client libraries with MinGW

2011-01-23 Thread XiaoboGu

Hi 

I am not so familiar with the PostgreSQL development team, but using a MinGW
compatible client side is important to us, so I'd like to start doing it
myself if any of you experts can help.

Cheers

Xiaobo Gu

> -邮件原件-
> 发件人: Andrew Dunstan [mailto:and...@dunslane.net]
> 发送时间: 2011年1月21日 23:25
> 收件人: Magnus Hagander
> 抄送: Robert Haas; XiaoboGu; pgsql-hackers@postgresql.org
> 主题: Re: [HACKERS] Is there a way to build PostgreSQL client libraries
with MinGW
> 
> 
> 
> On 01/21/2011 05:24 AM, Magnus Hagander wrote:
> >>
> >> That advice needs to be taken with a grain or two of salt. First, while
you
> >> probably should not use Cygwin postgres as a production server, it is
still
> >> the best way to run psql on Windows that I know of. And second, the
stuff
> > Yeah, I agree for psql the client tool (though it used to suck badly
> > if you were in a non-english locale, but they may have fixed that).
> > But not for PostgreSQL the full product. I guess we could add a
> > sentence about the client side, but it needs to be clear that the
> > non-sucky part only applies to the client.
> 
> 
> It's not so bad it can't be used for development, and I have known
> people who do that, and indeed I have deployed one very complex app
> developed in just that way.
> 
> More importantly from my POV, there is no support in the buildfarm for
> just building the client side, and I have no intention of providing it.
> So it's not insignificant for us to be able to continue supporting a
> complete build on Cygwin, however much you dislike it.
> 
> 
> >
> >> about not being able to generate 64-bit binaries with Mingw is no
longer
> >> true (that's why it's no longer called Mingw32), although it is true
that
> >> nobody I know has yet tried to do so. It's on my long TODO list, and
well
> >> worth doing. (Relying on one compiler is the techno equivalent of
> >> monolingualism, which my sister's bumper sticker used to tell me is a
> >> curable condition.)
> > It's true from the perspective of *postgresql* - you can't use those
> > compiler to generate 64-bit binaries of PostgreSQL. And it's referring
> > to "these builds", not the compiler itself.
> >
> > And I'm certainly not going to stand in the way of somebody adding
> > build support for it if they (you or others) want to spend time on it
> > - that patch should just include an update to that documentation
> > paragraph, of course.
> >
> > Personally, I'm going to put what time I can put into "windows build
> > system updates" into making us work with VS 2010 because I find that
> > more important - but that's just me personally.
> >
> 
> 
> VS2010 is important, no doubt. But clearly there's some demand for
> continued Mingw support, hence the OP's question.
> 
> As I've remarked before, I think we should support as many build
> platforms/environments as we can.
> 
> cheers
> 
> andrew


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Perl 5.12 complains about ecpg parser-hacking scripts

2011-01-23 Thread Andrew Dunstan




On 01/23/2011 06:11 AM, Michael Meskes wrote:

On Sat, Jan 22, 2011 at 08:40:13PM -0500, Andrew Dunstan wrote:

I think these really need to be rewritten from scratch. They look
like they were written by someone who never heard of Perl 5 (it's
only about 16 years old).

You might remember that we had this discussion before. The script was written
in awk and then translated to perl by a2p. We knew that this code was less than
optimal, but at least it works.


Oh, I'm sorry, I'd totally forgotten that. At least it explains why it 
looks like it's from a time warp. I bet the perl guys haven't touched 
a2p for many many years.



cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Perl 5.12 complains about ecpg parser-hacking scripts

2011-01-23 Thread Andy Colson


On 01/22/2011 09:28 PM, k...@shannon.id.au wrote:

On 23 January 2011 13:14, Andrew Dunstan  wrote:

But there are quite a few perlheads around. ISTR Matt Trout was muttering
about these scripts on IRC recently.


A quick cleanup of the check_rules.pl...

It's a starting point at least.






Oh!  Perl is my favorite.  Kris, if you're not going to, I'd love to work on 
this.

-Andy

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Use of O_DIRECT only for open_* sync options

2011-01-23 Thread Greg Smith


Bruce Momjian wrote:

xlogdefs.h says:

/*
 *  Because O_DIRECT bypasses the kernel buffers, and because we never
 *  read those buffers except during crash recovery, it is a win to use
 *  it in all cases where we sync on each write().  We could allow O_DIRECT
 *  with fsync(), but because skipping the kernel buffer forces writes out
 *  quickly, it seems best just to use it for O_SYNC.  It is hard to imagine
 *  how fsync() could be a win for O_DIRECT compared to O_SYNC and O_DIRECT.
 *  Also, O_DIRECT is never enough to force data to the drives, it merely
 *  tries to bypass the kernel cache, so we still need O_SYNC or fsync().
 */

This seems wrong because fsync() can win if there are two writes before
the sync call.  Can kernels not issue fsync() if the write was O_DIRECT?
If that is the cause, we should document it.
  


The comment does look busted, because you did imagine exactly a case 
where they might be combined.  The only incompatibility that I'm aware 
of is that O_DIRECT requires reads and writes to be aligned properly, so 
you can't use it in random application code unless it's aware of that.  
O_DIRECT and fsync are compatible; for example, MySQL allows combining 
the two:  http://dev.mysql.com/doc/refman/5.1/en/innodb-parameters.html


(That whole bit of documentation around innodb_flush_method includes 
some very interesting observations around O_DIRECT actually)


I'm starting to consider the idea that much of the performance gains 
seen on earlier systems with O_DIRECT was because it decreased CPU usage 
shuffling things into the OS cache, rather than its impact on avoiding 
pollution of said cache.  On Linux for example, its main accomplishment 
is decribed like this:  "File I/O is done directly to/from user space 
buffers."  
http://www.kernel.org/doc/man-pages/online/pages/man2/open.2.html  The 
earliest paper on the implementation suggests a big decrease in CPU 
overhead from that:  
http://www.ukuug.org/events/linux2001/papers/html/AArcangeli-o_direct.html


Impossible to guess whether that's more true ("CPU cache pollution is a 
bigger problem now") or less true ("drives are much slower relative to 
CPUs now") today.  I'm trying to remain agnostic and let the benchmarks 
offer an opinion instead.


--
Greg Smith   2ndQuadrant USg...@2ndquadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pg_basebackup for streaming base backups

On Thu, Jan 20, 2011 at 17:17, Magnus Hagander  wrote:
> On Thu, Jan 20, 2011 at 16:45, Bruce Momjian  wrote:
>> Do we envision pg_basebackup as something we will enahance, and if so,
>> should we consider a generic name?
>
> Well, it's certainly going to be enhanced. I think there are two main
> uses for it - backups, and setting up replication slaves. I can't see
> it expanding beyond those, really.

I've committed this with the current name, pg_basebackup, before the
bikeshed hits all the colors of the rainbow. If there's too much
uproar, we can always rename it - it's a lot easier now that we have
git :P

Base backups is something we discuss regularly, so it's not a new term.

And I don't see why people would be confused that this is a tool that
you run on the client (which can be the same machine) - afte rall, we
don't do pg_receive_dump, pg_receive_dumpall, pg_send_restore on those
tools.

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Perl 5.12 complains about ecpg parser-hacking scripts

2011-01-23 Thread Michael Meskes

On Sat, Jan 22, 2011 at 08:40:13PM -0500, Andrew Dunstan wrote:
> I think these really need to be rewritten from scratch. They look
> like they were written by someone who never heard of Perl 5 (it's
> only about 16 years old).

You might remember that we had this discussion before. The script was written
in awk and then translated to perl by a2p. We knew that this code was less than
optimal, but at least it works.

As I already said when the script was introduced, I would love to have a real
perl solution, but I'm not a perl programmer by any means.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at googlemail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] sepgsql contrib module