Re: [HACKERS] More Snow Leopard fun: multiarch problems while building plperl

2009-09-07 Thread Peter Eisentraut
On mån, 2009-09-07 at 23:13 -0400, Tom Lane wrote: > Anyway, the long and the short of it is that we are extracting this > value for perl_embed_ldflags: > > perl_embed_ldflags = -arch x86_64 -arch i386 -arch ppc > -L/usr/local/lib > -L/System/Library/Perl/5.10.0/darwin-thread-multi-2level/CO

Re: [HACKERS] LATERAL

2009-09-07 Thread Peter Eisentraut
On mån, 2009-09-07 at 19:06 -0400, Robert Haas wrote: > On Mon, Sep 7, 2009 at 3:43 AM, Peter Eisentraut wrote: > > Because joins can be reordered, whereas LATERAL creates a kind of > > syntactic sequence point for join reordering. To pick up your example: > > > >> But this doesn't [work]: > >> >

Re: [HACKERS] CREATE LIKE INCLUDING COMMENTS and STORAGES

2009-09-07 Thread Itagaki Takahiro
David Fetter wrote: > On Mon, Sep 07, 2009 at 12:15:21PM +0900, Itagaki Takahiro wrote: > > Here is a patch to implement the following items in our ToDo list: > > * Add CREATE TABLE LIKE ... INCLUDING COMMENTS > > * Have CREATE TABLE LIKE copy column storage parameters > > > > The syntax is

Re: [HACKERS] [Pgbuildfarm-members] Snow Leopard bison/flex build problem

2009-09-07 Thread Tom Lane
I wrote: > Yeah, I've confirmed this. It appears that Apple has absorbed this > as-yet-unreleased upstream patch into their "2.5.35" version: > http://flex.cvs.sourceforge.net/viewvc/flex/flex/flex.skl?r1=2.212&r2=2.213 > ... > However, I think we can work around it. AFAICS, the only reason ecpg

Re: [HACKERS] manually setting the command tag (was Re: 8.4: suppress_redundant_updates trigger vs. "Upsert" logic)

2009-09-07 Thread Pavel Stehule
2009/9/8 Alvaro Herrera : > Tom Lane escribió: >> Alvaro Herrera writes: >> > Pavel Stehule escribió: >> >> Isn't better to solve the the correct diagnostics for INSTEAD rules or >> >> triggers? >> >> > As far as I can tell it's not possible to do better without letting the >> > user put their ha

[HACKERS] More Snow Leopard fun: multiarch problems while building plperl

2009-09-07 Thread Tom Lane
Building plperl in CVS HEAD, the link step looks like this: gcc -no-cpp-precomp -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -g -bundle -multiply_defined suppress plperl.o spi_internal.o SPI.o -bundle_loader ../../../

Re: [HACKERS] LATERAL

2009-09-07 Thread Robert Haas
On Mon, Sep 7, 2009 at 10:08 PM, Stephen Frost wrote: > * Robert Haas (robertmh...@gmail.com) wrote: >> Fair enough.  I think I started to drift off in the direction of >> making that argument, but it wasn't really my point. > > To be honest, I'm not sure I agree with Tom here on the value of > req

Re: [HACKERS] LATERAL

2009-09-07 Thread Stephen Frost
* Robert Haas (robertmh...@gmail.com) wrote: > Fair enough. I think I started to drift off in the direction of > making that argument, but it wasn't really my point. To be honest, I'm not sure I agree with Tom here on the value of requiring a keyword to tell the system that you really mean what

Re: [HACKERS] LATERAL

2009-09-07 Thread Robert Haas
On Mon, Sep 7, 2009 at 9:12 PM, Stephen Frost wrote: > Robert, > > * Robert Haas (robertmh...@gmail.com) wrote: >> On Mon, Sep 7, 2009 at 7:47 PM, Tom Lane wrote: >> > Because as often as not, they're mistakes.  Please don't think >> > you're smarter than the spec here. >> >> You're frequently the

Re: [HACKERS] LATERAL

2009-09-07 Thread Stephen Frost
Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Mon, Sep 7, 2009 at 7:47 PM, Tom Lane wrote: > > Because as often as not, they're mistakes.  Please don't think > > you're smarter than the spec here. > > You're frequently the first to criticize the spec, but I have no > interest in secon

Re: [HACKERS] LATERAL

2009-09-07 Thread Alvaro Herrera
Robert Haas escribió: > I haven't got a copy of the spec, so that's a bit of a handicap. If > someone who does can look this up and comment on how it's supposed to > work, I would certainly appreciate that. My understanding of it is > currently based on random articles cherry-picked around the I

Re: [HACKERS] LATERAL

2009-09-07 Thread Robert Haas
On Mon, Sep 7, 2009 at 7:47 PM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Sep 7, 2009 at 3:43 AM, Peter Eisentraut wrote: >>> You could argue that the parser could infer the references and the >>> resultant join ordering restrictions automatically, but perhaps it was >>> deemed that an expl

Re: [HACKERS] LATERAL

2009-09-07 Thread Tom Lane
Robert Haas writes: > On Mon, Sep 7, 2009 at 3:43 AM, Peter Eisentraut wrote: >> You could argue that the parser could infer the references and the >> resultant join ordering restrictions automatically, but perhaps it was >> deemed that an explicit specification would be less error-prone. > Well,

Re: [HACKERS] manually setting the command tag (was Re: 8.4: suppress_redundant_updates trigger vs. "Upsert" logic)

2009-09-07 Thread Alvaro Herrera
Tom Lane escribió: > Alvaro Herrera writes: > > Pavel Stehule escribi�: > >> Isn't better to solve the the correct diagnostics for INSTEAD rules or > >> triggers? > > > As far as I can tell it's not possible to do better without letting the > > user put their hands on the tag. > > And how is th

[HACKERS] Snow Leopard Features

2009-09-07 Thread David E. Wheeler
On Sep 7, 2009, at 3:12 PM, Robert Creager wrote: Building from CVS, but on closer examination I do have Macports versions of bison/flex ahead of Apple's in the path. Does your work? Are you using the 32 or 64 bit kernel? Also, anyone tried compiling with LLVM and Clang? http://arstechn

Re: [HACKERS] manually setting the command tag (was Re: 8.4: suppress_redundant_updates trigger vs. "Upsert" logic)

2009-09-07 Thread Tom Lane
Alvaro Herrera writes: > Pavel Stehule escribió: >> Isn't better to solve the the correct diagnostics for INSTEAD rules or >> triggers? > As far as I can tell it's not possible to do better without letting the > user put their hands on the tag. And how is the user going to do better? For examp

Re: [HACKERS] LATERAL

2009-09-07 Thread Robert Haas
On Mon, Sep 7, 2009 at 3:43 AM, Peter Eisentraut wrote: > On Sun, 2009-09-06 at 23:59 -0400, Robert Haas wrote: >> Based on reading through this discussion, it appears that LATERAL is >> mostly a bit of syntactic sugar that requests that the parser allow >> you to reference tables at the same query

Re: [HACKERS] [Pgbuildfarm-members] Snow Leopard bison/flex build problem

2009-09-07 Thread Tom Lane
Robert Creager writes: > I've noticed on 7.4, Mac gets a spinlock compile error (see polecat > logs on buildfarm). Should I give up on the mac for 7.4? 7.4 thinks that Darwin only runs on PPC. We are not going to fix it. regards, tom lane -- Sent via pgsql-hackers m

Re: [HACKERS] manually setting the command tag (was Re: 8.4: suppress_redundant_updates trigger vs. "Upsert" logic)

2009-09-07 Thread Alvaro Herrera
Pavel Stehule escribió: > 2009/9/7 Alvaro Herrera : > > There are countless reports of trouble because somebody has an INSTEAD > > rule in the table, and the tag emits something that's not quite > > acceptable for some outer software layer.  The problem is that there's > > no way at all to make th

Re: [HACKERS] [Pgbuildfarm-members] Snow Leopard bison/flex build problem

2009-09-07 Thread Tom Lane
Robert Creager writes: > Next problems, with HEAD and 8_4, 8_3, 8_2, are here - all with the > same error: >-- Should succeed >DROP TABLESPACE testspace; > + ERROR: could not read directory "pg_tblspc/16388": Invalid argument Yeah, this is a known Snow Leopard bug --- see last month's

Re: [HACKERS] manually setting the command tag (was Re: 8.4: suppress_redundant_updates trigger vs. "Upsert" logic)

2009-09-07 Thread Pavel Stehule
2009/9/7 Alvaro Herrera : > Mark Reid wrote: > >> It'll similarly break any code where a result of "UPDATE 0" is assumed to >> indicate that the record does not exist. > > I wonder if this could be helped if the trigger had a way of overriding > the emitted command tag. > > There are countless repo

Re: [HACKERS] [Pgbuildfarm-members] Snow Leopard bison/flex build problem

2009-09-07 Thread Robert Creager
On Sep 7, 2009, at 4:08 PM, Tom Lane wrote: Any feelings about that? Should I just hit everything back to 7.4 to be safe? I've noticed on 7.4, Mac gets a spinlock compile error (see polecat logs on buildfarm). Should I give up on the mac for 7.4? Cheers, Rob Sent from my iPhone -- S

Re: [HACKERS] [Pgbuildfarm-members] Snow Leopard bison/flex build problem

2009-09-07 Thread Robert Creager
On Sep 7, 2009, at 2:41 PM, Dave Page wrote: On 9/7/09, Robert Creager wrote: On Sep 7, 2009, at 2:17 PM, Dave Page wrote: FYI, I've been building from source on Snow Leopard without any problems. If your building from the official tarball, bison/flex are not used. I'm building from CV

Re: [HACKERS] [Pgbuildfarm-members] Snow Leopard bison/flex build problem

2009-09-07 Thread Tom Lane
Robert Creager writes: > On Sep 7, 2009, at 1:18 PM, Tom Lane wrote: >> Robert Creager writes: >>> extern yy_size_t yyleng; >> >> Bizarre --- my copy of flex 2.5.35 definitely puts out "int", and >> so does everybody else's. Did Apple take it on their own head to >> change this? > Apparently s

[HACKERS] manually setting the command tag (was Re: 8.4: suppress_redundant_updates trigger vs. "Upsert" logic)

2009-09-07 Thread Alvaro Herrera
Mark Reid wrote: > It'll similarly break any code where a result of "UPDATE 0" is assumed to > indicate that the record does not exist. I wonder if this could be helped if the trigger had a way of overriding the emitted command tag. There are countless reports of trouble because somebody has an

Re: [HACKERS] [Pgbuildfarm-members] Snow Leopard bison/flex build problem

2009-09-07 Thread Dave Page
On 9/7/09, Robert Creager wrote: > > On Sep 7, 2009, at 2:17 PM, Dave Page wrote: > >> >> FYI, I've been building from source on Snow Leopard without any >> problems. > > If your building from the official tarball, bison/flex are not used. > I'm building from CVS, where bison/flex are used. Build

Re: [HACKERS] [Pgbuildfarm-members] Snow Leopard bison/flex build problem

2009-09-07 Thread Robert Creager
On Sep 7, 2009, at 2:17 PM, Dave Page wrote: FYI, I've been building from source on Snow Leopard without any problems. If your building from the official tarball, bison/flex are not used. I'm building from CVS, where bison/flex are used. Cheers, rob -- Sent via pgsql-hackers mailing

Re: [HACKERS] [Pgbuildfarm-members] Snow Leopard bison/flex build problem

2009-09-07 Thread Robert Creager
On Sep 7, 2009, at 1:18 PM, Tom Lane wrote: Robert Creager writes: On Sep 7, 2009, at 11:29 AM, Andrew Dunstan wrote: Please try building by hand and examine the files to find out what the conflict is between these declarations. pgc.c - 161: extern yy_size_t yyleng; Bizarre --- my co

Re: [HACKERS] [Pgbuildfarm-members] Snow Leopard bison/flex build problem

2009-09-07 Thread Dave Page
On 9/7/09, Robert Creager wrote: > > On Sep 7, 2009, at 1:18 PM, Tom Lane wrote: > >> Robert Creager writes: >>> On Sep 7, 2009, at 11:29 AM, Andrew Dunstan wrote: Please try building by hand and examine the files to find out what the conflict is between these declarations. >> >>> pgc.

Re: [HACKERS] [Pgbuildfarm-members] Snow Leopard bison/flex build problem

2009-09-07 Thread Robert Creager
On Sep 7, 2009, at 1:18 PM, Tom Lane wrote: Robert Creager writes: On Sep 7, 2009, at 11:29 AM, Andrew Dunstan wrote: Please try building by hand and examine the files to find out what the conflict is between these declarations. pgc.c - 161: extern yy_size_t yyleng; Bizarre --- my c

Re: [HACKERS] [Pgbuildfarm-members] Snow Leopard bison/flex build problem

2009-09-07 Thread Tom Lane
Robert Creager writes: > On Sep 7, 2009, at 11:29 AM, Andrew Dunstan wrote: >> Please try building by hand and examine the files to find out what >> the conflict is between these declarations. > pgc.c - 161: > extern yy_size_t yyleng; Bizarre --- my copy of flex 2.5.35 definitely puts out "in

Re: [HACKERS] [Pgbuildfarm-members] Snow Leopard bison/flex build problem

2009-09-07 Thread Robert Creager
On Sep 7, 2009, at 11:29 AM, Andrew Dunstan wrote: Robert Creager wrote: Upgraded to Snow Leopard Saturday, and am having problems building now. The build logs are here http://buildfarm.postgresql.org/cgi-bin/show_status.pl?member=polecat And the failing part is here: make -C preproc a

Re: [HACKERS] Patch: update Bonjour support to the newer non-deprecated API

2009-09-07 Thread Alvaro Herrera
Tom Lane wrote: > Alvaro Herrera writes: > > The source is here: > > http://avahi.sourcearchive.com/documentation/0.6.25-1ubuntu1/avahi-compat-libdns__sd_2compat_8c-source.html > > After reading that code, I am content to remain forcibly non compatible > with it. If we relied on this it would in

Re: [HACKERS] Patch: update Bonjour support to the newer non-deprecated API

2009-09-07 Thread Tom Lane
Alvaro Herrera writes: > The source is here: > http://avahi.sourcearchive.com/documentation/0.6.25-1ubuntu1/avahi-compat-libdns__sd_2compat_8c-source.html After reading that code, I am content to remain forcibly non compatible with it. If we relied on this it would inject threading into the post

Re: [HACKERS] Patch: update Bonjour support to the newer non-deprecated API

2009-09-07 Thread Tom Lane
Alvaro Herrera writes: > Tom Lane wrote: >> Hmm, I read in their documentation that the dns_sd.h interface was >> deprecated, but not that it had been intentionally disabled. > I think it is supposed to work; the code suggests that it should. I > can't quite find out what the error number is sup

Re: [HACKERS] Patch: update Bonjour support to the newer non-deprecated API

2009-09-07 Thread Tom Lane
David Fetter writes: > On Mon, Sep 07, 2009 at 12:50:37PM -0400, Tom Lane wrote: >> The two possibilities for that seem to be to change the meaning of >> bonjour_name = '' (have it mean "no advertisement" instead of >> "default to service name = computer's name"), or to add a separate >> boolean G

Re: [HACKERS] [Pgbuildfarm-members] Snow Leopard bison/flex build problem

2009-09-07 Thread Andrew Dunstan
Robert Creager wrote: Upgraded to Snow Leopard Saturday, and am having problems building now. The build logs are here http://buildfarm.postgresql.org/cgi-bin/show_status.pl?member=polecat And the failing part is here: make -C preproc all make -C ../../../../src/port all make[5]: Nothing to b

Re: [HACKERS] CREATE LIKE INCLUDING COMMENTS and STORAGES

2009-09-07 Thread David Fetter
On Mon, Sep 07, 2009 at 12:15:21PM +0900, Itagaki Takahiro wrote: > Here is a patch to implement the following items in our ToDo list: > * Add CREATE TABLE LIKE ... INCLUDING COMMENTS > * Have CREATE TABLE LIKE copy column storage parameters > > The syntax is: > CREATE TABLE clone_table (L

Re: [HACKERS] Patch: update Bonjour support to the newer non-deprecated API

2009-09-07 Thread David Fetter
On Mon, Sep 07, 2009 at 12:50:37PM -0400, Tom Lane wrote: > > The two possibilities for that seem to be to change the meaning of > bonjour_name = '' (have it mean "no advertisement" instead of > "default to service name = computer's name"), or to add a separate > boolean GUC. If the latter, is th

Re: [HACKERS] Patch: update Bonjour support to the newer non-deprecated API

2009-09-07 Thread Alvaro Herrera
Tom Lane wrote: > Alvaro Herrera writes: > > *** WARNING *** The program 'postgres' uses the Apple Bonjour compatibility > > layer of Avahi. > > *** WARNING *** Please fix your application to use the native API of Avahi! > > *** WARNING *** For more information see > >

Re: [HACKERS] Triggers on columns

2009-09-07 Thread David Fetter
On Mon, Sep 07, 2009 at 07:53:01PM +0900, Itagaki Takahiro wrote: > However, to be honest, I think standard-compliant column trigger is > useless... I'm thinking additional extension for triggers -- if we > want to check modifications of actual values, it could be defined > as: > > CREATE TRIG

Re: [HACKERS] Patch: update Bonjour support to the newer non-deprecated API

2009-09-07 Thread Tom Lane
Alvaro Herrera writes: > *** WARNING *** The program 'postgres' uses the Apple Bonjour compatibility > layer of Avahi. > *** WARNING *** Please fix your application to use the native API of Avahi! > *** WARNING *** For more information see >

Re: [HACKERS] Patch: update Bonjour support to the newer non-deprecated API

2009-09-07 Thread Alvaro Herrera
Alvaro Herrera wrote: > Hmm, but it doesn't link unless I manually add -ldns_sd to the link > command. And then it throws a warning on start, and fails to work anyway: *** WARNING *** The program 'postgres' uses the Apple Bonjour compatibility layer of Avahi. *** WARNING *** Please fix your app

Re: [HACKERS] Patch: update Bonjour support to the newer non-deprecated API

2009-09-07 Thread Alvaro Herrera
Alvaro Herrera wrote: > Tom Lane wrote: > > > In principle this might enable use of Bonjour on non-Apple OSes, but > > I'm not personally interested enough to test that ... > > With this patch and Avahi's compatibility headers I can successfully > compile --enable-bonjour on my Debian system. I

Re: [HACKERS] _WIN32_WINNT should be 0x0501 in win32.h

2009-09-07 Thread Andrew Chernow
Magnus Hagander wrote: On Mon, Sep 7, 2009 at 15:14, Andrew Chernow wrote: Magnus Hagander wrote: On Monday, September 7, 2009, Itagaki Takahiro wrote: We should define _WIN32_WINNT as 0x0500 in src/include/port/win32.h, but it should be 0x0501 (Windows XP) because IPPROTO_IPV6 will be define

Re: [HACKERS] Patch: update Bonjour support to the newer non-deprecated API

2009-09-07 Thread Alvaro Herrera
Tom Lane wrote: > In principle this might enable use of Bonjour on non-Apple OSes, but > I'm not personally interested enough to test that ... With this patch and Avahi's compatibility headers I can successfully compile --enable-bonjour on my Debian system. I haven't tested it. -- Alvaro Herre

Re: [HACKERS] _WIN32_WINNT should be 0x0501 in win32.h

2009-09-07 Thread Andrew Chernow
Magnus Hagander wrote: On Monday, September 7, 2009, Itagaki Takahiro wrote: We should define _WIN32_WINNT as 0x0500 in src/include/port/win32.h, but it should be 0x0501 (Windows XP) because IPPROTO_IPV6 will be defined only if _WIN32_WINNT >= 0x0501 in the recent Micosoft SDKs. Hi! Have you

Re: [HACKERS] _WIN32_WINNT should be 0x0501 in win32.h

2009-09-07 Thread Magnus Hagander
On Mon, Sep 7, 2009 at 15:14, Andrew Chernow wrote: > Magnus Hagander wrote: >> >> On Monday, September 7, 2009, Itagaki Takahiro >> wrote: >>> >>> We should define _WIN32_WINNT as 0x0500 in src/include/port/win32.h, >>> but it should be 0x0501 (Windows XP) because IPPROTO_IPV6 will be >>> defined

Re: [HACKERS] _WIN32_WINNT should be 0x0501 in win32.h

2009-09-07 Thread Magnus Hagander
On Mon, Sep 7, 2009 at 07:53, Itagaki Takahiro wrote: > > Magnus Hagander wrote: > >> Have you verified that binaries compiled that way still run on windows >> 2000? I had checking that on my list before making this change... > > No, I don't have Windows 2000. > > BTW, there is no Windows 2000 ani

Re: [HACKERS] Triggers on columns

2009-09-07 Thread Itagaki Takahiro
e Software Center standard-column-trigger-20090907.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] Rename StrNCpy to avoid conflictions on win32

2009-09-07 Thread Peter Eisentraut
On Mon, 2009-09-07 at 11:36 +0200, Magnus Hagander wrote: > On Mon, Sep 7, 2009 at 04:40, Itagaki > Takahiro wrote: > > There might be some places to replace it to strlcpy() instead. > > Can't comment on that without looking at the code, but it wouldn't surprise > me. There are some performance

Re: [HACKERS] Rename StrNCpy to avoid conflictions on win32

2009-09-07 Thread Magnus Hagander
On Mon, Sep 7, 2009 at 04:40, Itagaki Takahiro wrote: > We define StrNCpy() macro in c.h, but it conflicts another macro > defined in Microsoft SDKs: > >    C:\Program Files\Microsoft SDKs\Windows\v6.1\Include\shlwapi.h(435) >        : warning C4005: 'StrNCpy' : macro redefinition > > Can we rename

Re: [HACKERS] Triggers on columns

2009-09-07 Thread Peter Eisentraut
On Mon, 2009-09-07 at 11:20 +0900, Itagaki Takahiro wrote: > We are discussing how to determine modified columns > (UPDATE-target vs. changes of actual values), but in the patch > I used value-based checking. The reasons are: If you implement a new feature using syntax from the standard, you have

Re: [HACKERS] LATERAL

2009-09-07 Thread Peter Eisentraut
On Sun, 2009-09-06 at 23:59 -0400, Robert Haas wrote: > Based on reading through this discussion, it appears that LATERAL is > mostly a bit of syntactic sugar that requests that the parser allow > you to reference tables at the same query level. Assuming that the > necessary executor support were