Re: [HACKERS] LATERAL
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 present (which it's currently not), it's unclear to me why one couldn't simply allow such references unconditionally. 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]: select g, h from generate_series(1,10) g, generate_series(1,g) h; You need to constrain the order of the from items in some way so the g refers to something well-defined. That's what LATERAL does. 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. -- 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] Triggers on columns
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 to implement the semantics of the standard. If you don't like the semantics of the standard, use a different syntax. 2. IMHO, almost users don't expect their triggers are not called if the actual values are not modified. Well, as we saw upthread, there can be different valid opinions on this. But consider the following: - Statement triggers are called even if the table was not actually changed in a semantically significant way. - Row triggers are called even if the row was not actually changed in a semantically significant way. Therefore, it cannot be completely unexpected if column triggers are called even if the column was not actually changed in a semantically significant way. -- 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
On Mon, Sep 7, 2009 at 04:40, Itagaki Takahiroitagaki.takah...@oss.ntt.co.jp 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 StrNCpy() macro to another name? (ex. pg_strncpy) +1. 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. -- 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] Rename StrNCpy to avoid conflictions on win32
On Mon, 2009-09-07 at 11:36 +0200, Magnus Hagander wrote: On Mon, Sep 7, 2009 at 04:40, Itagaki Takahiroitagaki.takah...@oss.ntt.co.jp 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 tradeoffs between these variants, and we already did change all (most?) of the not performance-critical calls to strlcpy a while ago. -- 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] Triggers on columns
Peter Eisentraut pete...@gmx.net wrote: Therefore, it cannot be completely unexpected if column triggers are called even if the column was not actually changed in a semantically significant way. Ok, the attached patch implements standard-compliant version of column trigger. Retrieving modified columns is not so difficult as I expected. It is in: rt_fetch(relinfo-ri_RangeTableIndex, estate-es_range_table)-modifiedCols and the information are passed from caller to trigger routines. 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 TRIGGER trig BEFORE UPDATE ON tbl FOR EACH ROW WHEN (NEW.col OLD.col) EXECUTE PROCEDURE trigger_func(); Regards, --- ITAGAKI Takahiro NTT Open Source 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] _WIN32_WINNT should be 0x0501 in win32.h
On Mon, Sep 7, 2009 at 07:53, Itagaki Takahiroitagaki.takah...@oss.ntt.co.jp wrote: Magnus Hagander mag...@hagander.net 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 animal in the BuildFarm. We cannot support win2k at all, no? I could've sworn we did, but clearly we don't :( I guess that means we're already in best effort mode on it. And to be honest, Microsoft haven't supported Windows 2000 mainstream since 2005 (they do provided extended support until next year though). Anyway, this *should* work on Win2k as well, so I have applied it. We also have _WIN32_WINNT defined in pg_ctl.c, so I updated that one to be the same. -- 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] _WIN32_WINNT should be 0x0501 in win32.h
On Mon, Sep 7, 2009 at 15:14, Andrew Chernowa...@esilo.com wrote: Magnus Hagander wrote: On Monday, September 7, 2009, Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp 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 verified that binaries compiled that way still run on windows 2000? I had checking that on my list before making this change... Yes they do. Our current project uses 0x0501. Windows 2000 is part of our build farm and a target platform for that project. We set WINVER to the same value as well. Thanks, then we should be good to go. If you're actively working with win2k, any chance you can get us a buildfarm machine on it? :-) -- 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] _WIN32_WINNT should be 0x0501 in win32.h
Magnus Hagander wrote: On Monday, September 7, 2009, Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp 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 verified that binaries compiled that way still run on windows 2000? I had checking that on my list before making this change... Yes they do. Our current project uses 0x0501. Windows 2000 is part of our build farm and a target platform for that project. We set WINVER to the same value as well. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.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] Patch: update Bonjour support to the newer non-deprecated API
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 Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 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] _WIN32_WINNT should be 0x0501 in win32.h
Magnus Hagander wrote: On Mon, Sep 7, 2009 at 15:14, Andrew Chernowa...@esilo.com wrote: Magnus Hagander wrote: On Monday, September 7, 2009, Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp 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 verified that binaries compiled that way still run on windows 2000? I had checking that on my list before making this change... Yes they do. Our current project uses 0x0501. Windows 2000 is part of our build farm and a target platform for that project. We set WINVER to the same value as well. Thanks, then we should be good to go. If you're actively working with win2k, any chance you can get us a buildfarm machine on it? :-) Sure. I think its an image running on one of our ESXi servers. I'll look into it tomorrow, not supposed to be working today ;) -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.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] Patch: update Bonjour support to the newer non-deprecated API
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 haven't tested it. Hmm, but it doesn't link unless I manually add -ldns_sd to the link command. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 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] Patch: update Bonjour support to the newer non-deprecated API
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 application to use the native API of Avahi! *** WARNING *** For more information see http://0pointer.de/avahi-compat?s=libdns_sde=postgres LOG: DNSServiceRegister() failed: error code -65540 So we're not better than when we started, but it doesn't cause any problem if not enabled. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- 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: update Bonjour support to the newer non-deprecated API
Alvaro Herrera alvhe...@commandprompt.com 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 http://0pointer.de/avahi-compat?s=libdns_sde=postgres LOG: DNSServiceRegister() failed: error code -65540 Hmm, I read in their documentation that the dns_sd.h interface was deprecated, but not that it had been intentionally disabled. Seems like they want to drive users away rather than attract them. So we're not better than when we started, but it doesn't cause any problem if not enabled. The patch as I gave it intentionally didn't change any user-visible behavior, but one thing that is bothering me is that if USE_BONJOUR is selected, the postmaster will *always* try to advertise itself via DNS-SD. There's no provision for enabling the feature or not at run time, which is a bad thing for packagers: they have to decide for their users whether to turn it on. There was discussion in connection with the Avahi patch last year to the effect that some people thought advertising the postmaster might be a security issue for them. So I'm thinking we ought to fix that while we're messing with it. 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 the default 'on' or 'off'? Opinions? 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] Triggers on columns
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 TRIGGER trig BEFORE UPDATE ON tbl FOR EACH ROW WHEN (NEW.col OLD.col) EXECUTE PROCEDURE trigger_func(); That should probably read: CREATE TRIGGER trig BEFORE UPDATE ON tbl FOR EACH ROW WHEN (NEW.col IS DISTINCT FROM OLD.col) EXECUTE PROCEDURE trigger_func(); Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- 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: update Bonjour support to the newer non-deprecated API
Tom Lane wrote: Alvaro Herrera alvhe...@commandprompt.com 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 http://0pointer.de/avahi-compat?s=libdns_sde=postgres LOG: DNSServiceRegister() failed: error code -65540 Hmm, I read in their documentation that the dns_sd.h interface was deprecated, but not that it had been intentionally disabled. Seems like they want to drive users away rather than attract them. I think it is supposed to work; the code suggests that it should. I can't quite find out what the error number is supposed to mean though. The source is here: http://avahi.sourcearchive.com/documentation/0.6.25-1ubuntu1/avahi-compat-libdns__sd_2compat_8c-source.html ... ah! here it is -- BadParam: http://avahi.sourcearchive.com/documentation/0.6.25-1ubuntu1/dns__sd_8h-source.html The patch as I gave it intentionally didn't change any user-visible behavior, but one thing that is bothering me is that if USE_BONJOUR is selected, the postmaster will *always* try to advertise itself via DNS-SD. There's no provision for enabling the feature or not at run time, which is a bad thing for packagers: they have to decide for their users whether to turn it on. There was discussion in connection with the Avahi patch last year to the effect that some people thought advertising the postmaster might be a security issue for them. So I'm thinking we ought to fix that while we're messing with it. 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 the default 'on' or 'off'? Opinions? I have a mild preference towards having a new GUC to shut it off explicitely; and the default should be off to avoid the possible security hole (equivalent to having listen_addresses default to localhost, I think. On the other hand, if listen_addresses is set to that, there is no security hole. I assume we're only publishing on addresses we're listening on, not all addresses?) -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 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] Patch: update Bonjour support to the newer non-deprecated API
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 the default 'on' or 'off'? Opinions? +1 for separate boolean GUC, default off. I know extra GUCs aren't great, but I don't see another way :/ Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- 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] CREATE LIKE INCLUDING COMMENTS and STORAGES
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 (LIKE template_table INCLUDING COMMENTS) -- also copy comments on columns. CREATE TABLE clone_table (LIKE template_table INCLUDING STORAGES) This should probably read INCLUDING STORAGE (singular) instead of STORAGES. Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- 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] [Pgbuildfarm-members] Snow Leopard bison/flex build problem
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 be done for `all'. /usr/bin/perl ./parse.pl . ../../../backend/parser/gram.y preproc.y /usr/bin/bison -d -o preproc.c preproc.y /usr/bin/flex -o'pgc.c' pgc.l /opt/local/bin/ccache gcc -no-cpp-precomp -I/opt/local/include -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -g -DECPG_COMPILE -I../include -I../../../../src/interfaces/ecpg/include -I. -I. -DMAJOR_VERSION=4 -DMINOR_VERSION=6 -DPATCHLEVEL=0 -I../../../../src/include -I/usr/include/libxml2 -c -o preproc.o preproc.c In file included from preproc.y:12065: pgc.c:161: error: conflicting types for 'yyleng' extern.h:43: error: previous declaration of 'yyleng' was here pgc.c:288: error: conflicting types for 'yyleng' extern.h:43: error: previous declaration of 'yyleng' was here make[4]: *** [preproc.o] Error 1 make[3]: *** [all] Error 2 make[2]: *** [all] Error 2 make[1]: *** [all] Error 2 make: *** [all] Error 2 Please try building by hand and examine the files to find out what the conflict is between these declarations. This is really a -hackers question. 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: update Bonjour support to the newer non-deprecated API
David Fetter da...@fetter.org 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 GUC. If the latter, is the default 'on' or 'off'? Opinions? +1 for separate boolean GUC, default off. I know extra GUCs aren't great, but I don't see another way :/ Yeah, the default service name seems like a potentially useful behavior in some contexts, so taking that behavior away doesn't seem nice. Separate bool it is... 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] Patch: update Bonjour support to the newer non-deprecated API
Alvaro Herrera alvhe...@commandprompt.com 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 supposed to mean though. The source is here: http://avahi.sourcearchive.com/documentation/0.6.25-1ubuntu1/avahi-compat-libdns__sd_2compat_8c-source.html ... ah! here it is -- BadParam: http://avahi.sourcearchive.com/documentation/0.6.25-1ubuntu1/dns__sd_8h-source.html Interesting. I coded the call to default everything it could, but maybe Avahi is a little less forgiving about NULL parameters. In particular it wouldn't surprise me if they thought that there *must* be a callback function --- we're playing fast and loose with the API by not bothering to check for a response from the daemon. 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] Patch: update Bonjour support to the newer non-deprecated API
Alvaro Herrera alvhe...@commandprompt.com 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 postmaster, which was precisely the thing that got the previous Avahi patch rejected last year :-( Apple's implementation of the same API does not appear to require any threading: http://www.opensource.apple.com/source/mDNSResponder/mDNSResponder-176.3/mDNSShared/dnssd_clientstub.c Hm, seems to be Apache license ... 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] Patch: update Bonjour support to the newer non-deprecated API
Tom Lane wrote: Alvaro Herrera alvhe...@commandprompt.com 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 postmaster, which was precisely the thing that got the previous Avahi patch rejected last year :-( Should we inject some sort of compile-time rejection of the compatibility API? Like, say #ifdef AVAHI_SERVICE_COOKIE #error The Avahi implementation is incompatible #endif inside some #ifdef BONJOUR block? -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- 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] [Pgbuildfarm-members] Snow Leopard bison/flex build problem
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 all make -C ../../../../src/port all make[5]: Nothing to be done for `all'. /usr/bin/perl ./parse.pl . ../../../backend/parser/gram.y preproc.y /usr/bin/bison -d -o preproc.c preproc.y /usr/bin/flex -o'pgc.c' pgc.l /opt/local/bin/ccache gcc -no-cpp-precomp -I/opt/local/include - Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after- statement -Wendif-labels -fno-strict-aliasing -fwrapv -g - DECPG_COMPILE -I../include -I../../../../src/interfaces/ecpg/ include -I. -I. -DMAJOR_VERSION=4 -DMINOR_VERSION=6 -DPATCHLEVEL=0 - I../../../../src/include -I/usr/include/libxml2 -c -o preproc.o preproc.c In file included from preproc.y:12065: pgc.c:161: error: conflicting types for 'yyleng' extern.h:43: error: previous declaration of 'yyleng' was here pgc.c:288: error: conflicting types for 'yyleng' extern.h:43: error: previous declaration of 'yyleng' was here make[4]: *** [preproc.o] Error 1 make[3]: *** [all] Error 2 make[2]: *** [all] Error 2 make[1]: *** [all] Error 2 make: *** [all] Error 2 Please try building by hand and examine the files to find out what the conflict is between these declarations. This is really a -hackers question. pgc.c - 161: extern yy_size_t yyleng; extern.h - 43 : extern int yylineno, yyleng; Thanks, Rob -- 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] [Pgbuildfarm-members] Snow Leopard bison/flex build problem
Robert Creager rob...@logicalchaos.org 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 int, and so does everybody else's. Did Apple take it on their own head to change this? 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] [Pgbuildfarm-members] Snow Leopard bison/flex build problem
On Sep 7, 2009, at 1:18 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Creager rob...@logicalchaos.org 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 int, and so does everybody else's. Did Apple take it on their own head to change this? regards, tom lane I'll try the macports version, and see what happens. Cheers, Rob Sent from my iPhone -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- 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] [Pgbuildfarm-members] Snow Leopard bison/flex build problem
On 9/7/09, Robert Creager rob...@logicalchaos.org wrote: On Sep 7, 2009, at 1:18 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Creager rob...@logicalchaos.org 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 int, and so does everybody else's. Did Apple take it on their own head to change this? regards, tom lane I'll try the macports version, and see what happens. FYI, I've been building from source on Snow Leopard without any problems. -- Dave Page EnterpriseDB UK: 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] [Pgbuildfarm-members] Snow Leopard bison/flex build problem
On Sep 7, 2009, at 1:18 PM, Tom Lane wrote: Robert Creager rob...@logicalchaos.org 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 int, and so does everybody else's. Did Apple take it on their own head to change this? Apparently so - the /opt version is from macports. It works. % /opt/local/bin/flex --version flex 2.5.35 % /usr/bin/flex --version flex 2.5.35 Next problems, with HEAD and 8_4, 8_3, 8_2, are here - all with the same error: http://buildfarm.postgresql.org/cgi-bin/show_status.pl?member=polecat ... == running regression test queries== test tablespace ... FAILED ... == pgsql.41144/src/test/regress/regression.diffs === *** /usr/local/src/build-farm-3.2/builds/HEAD/pgsql.41144/src/test/ regress/expected/tablespace.out Mon Sep 7 14:03:30 2009 --- /usr/local/src/build-farm-3.2/builds/HEAD/pgsql.41144/src/test/ regress/results/tablespace.out Mon Sep 7 14:03:43 2009 *** *** 73,75 --- 73,76 drop cascades to table testschema.atable -- Should succeed DROP TABLESPACE testspace; + ERROR: could not read directory pg_tblspc/16388: Invalid argument Sigh, Rob -- 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] [Pgbuildfarm-members] Snow Leopard bison/flex build problem
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 list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Pgbuildfarm-members] Snow Leopard bison/flex build problem
On 9/7/09, Robert Creager rob...@logicalchaos.org 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. Building from CVS, but on closer examination I do have Macports versions of bison/flex ahead of Apple's in the path. -- Dave Page EnterpriseDB UK: 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
[HACKERS] manually setting the command tag (was Re: 8.4: suppress_redundant_updates trigger vs. Upsert logic)
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 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 the command tag behave! For example, we could offer a new SPI function, say SPI_settag(), which sets the command tag string. PL/pgSQL could expose this via a new command, for example COMMANDTAG. So if there's a function that is used in a INSTEAD rule for (say) an UPDATE, this function would finish with COMMANDTAG 'UPDATE num' and make the external framework happy. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- 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] [Pgbuildfarm-members] Snow Leopard bison/flex build problem
Robert Creager rob...@logicalchaos.org writes: On Sep 7, 2009, at 1:18 PM, Tom Lane wrote: Robert Creager rob...@logicalchaos.org 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 so - the /opt version is from macports. It works. [ Well, I knew I was going to be buying a copy of Snow Leopard sometime soon. One trip to the Apple store later ... ] 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.212r2=2.213 This is probably not the brightest thing the flex developers have ever done, as there is now absolutely no way to predict the type of yyleng externally to the generated scan.c file. They might as well not export it at all. However, I think we can work around it. AFAICS, the only reason ecpg has an extern for yyleng is because preproc.y's make_name() uses it, and there doesn't seem to be any compelling reason why that function shouldn't just do mm_strdup(yytext) instead. I don't see any other places where we are referring to yyleng outside of a scanner file. (Alternatively, make_name() could be moved into pgc.l, but I doubt it's worth the work to avoid one extra strlen calculation.) Presumably, versions of flex containing this change will start to show up at other places besides Apple sometime soon. So I'm thinking we need to back-patch the fix to whatever branches we think are likely to get compiled from CVS on newer platforms. Any feelings about that? Should I just hit everything back to 7.4 to be safe? 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] [Pgbuildfarm-members] Snow Leopard bison/flex build problem
On Sep 7, 2009, at 2:41 PM, Dave Page dp...@pgadmin.org wrote: On 9/7/09, Robert Creager rob...@logicalchaos.org 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. Building from CVS, but on closer examination I do have Macports versions of bison/flex ahead of Apple's in the path. Does your make config work? Are you using the 32 or 64 bit kernel? Cheers, Rob Sent from my iPhone -- 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] [Pgbuildfarm-members] Snow Leopard bison/flex build problem
On Sep 7, 2009, at 4:08 PM, Tom Lane t...@sss.pgh.pa.us 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 -- 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] manually setting the command tag (was Re: 8.4: suppress_redundant_updates trigger vs. Upsert logic)
2009/9/7 Alvaro Herrera alvhe...@commandprompt.com: 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 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 the command tag behave! For example, we could offer a new SPI function, say SPI_settag(), which sets the command tag string. PL/pgSQL could expose this via a new command, for example COMMANDTAG. Isn't better to solve the the correct diagnostics for INSTEAD rules or triggers? Pavel So if there's a function that is used in a INSTEAD rule for (say) an UPDATE, this function would finish with COMMANDTAG 'UPDATE num' and make the external framework happy. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- 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] [Pgbuildfarm-members] Snow Leopard bison/flex build problem
Robert Creager rob...@logicalchaos.org 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 report from Jan Otto. I think our plan is to wait and see if Apple fixes it in 10.6.1 before we consider whether it's worth installing a kluge workaround. 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] manually setting the command tag (was Re: 8.4: suppress_redundant_updates trigger vs. Upsert logic)
Pavel Stehule escribió: 2009/9/7 Alvaro Herrera alvhe...@commandprompt.com: 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 the command tag behave! For example, we could offer a new SPI function, say SPI_settag(), which sets the command tag string. PL/pgSQL could expose this via a new command, for example COMMANDTAG. 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. The problem is figuring out what command should determine the tag. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- 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] [Pgbuildfarm-members] Snow Leopard bison/flex build problem
Robert Creager rob...@logicalchaos.org 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 mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] LATERAL
On Mon, Sep 7, 2009 at 3:43 AM, Peter Eisentrautpete...@gmx.net 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 level. Assuming that the
necessary executor support were present (which it's currently not),
it's unclear to me why one couldn't simply allow such references
unconditionally.
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]:
select g, h from generate_series(1,10) g, generate_series(1,g) h;
You need to constrain the order of the from items in some way so the g
refers to something well-defined. That's what LATERAL does.
I don't think so. All joins constrain the join order, but none of
them except FULL JOIN constrain it completely, and this is no
exception. Consider this query:
select * from foo f, generate_series(1, 10) g, generate_series(1, g) h
WHERE f.x = g;
There are two legal join orderings here: f {g h} and {f g} h, just as
there would be for a three-way inner join:
select * from foo f, goo g, hoo h WHERE f.x = g.x and g.x = h.x;
I believe that the join-order restrictions imposed by a LATERAL SRF
are identical to those that would be imposed by an inner join against
a table with join clauses referencing the same tables used in the
inputs to the SRF. What is different is that there is only one
possible method of implementing the join, namely, for each outer row,
evaluate the SRF. We can't hash or merge, and we can't swap the inner
and outer rels, but we do still have a choice as to whether to join
against h before or after joining against f.
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, the irony is that our current code does already infer the
references - and then disallows them. It seems to me that if we
implement LATERAL(), we're basically going to be conditionalizing
those checks on whether the relevant subexpression has been wrapped in
LATERAL or not. Introducing a new keyword would make sense if it were
possible to write a query that is valid without LATERAL(), but means
something different with LATERAL() - but I'm currently unable to
devise such a scenario. Whether this is for want of creativity or
because none exists I'm not entirely sure. Any ideas?
...Robert
--
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] manually setting the command tag (was Re: 8.4: suppress_redundant_updates trigger vs. Upsert logic)
Tom Lane escribió: Alvaro Herrera alvhe...@commandprompt.com 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 example, what if there are two triggers trying to set the result, perhaps because two different commands have been generated by DO ALSO rules? We would allow the user to set a policy. This provides the mechanism for doing it. Right now there is no mechanism at all and we fail to do anything. I don't think that put it on the user's shoulders is a good solution. Is there a better idea? -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Snow Leopard Features
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 make config work? Are you using the 32 or 64 bit kernel? Also, anyone tried compiling with LLVM and Clang? http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/9 And are there places where PostgreSQL can take advantage of GCD? http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/12 Cheers, David -- 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] manually setting the command tag (was Re: 8.4: suppress_redundant_updates trigger vs. Upsert logic)
Alvaro Herrera alvhe...@commandprompt.com 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 example, what if there are two triggers trying to set the result, perhaps because two different commands have been generated by DO ALSO rules? I don't think that put it on the user's shoulders is a good solution. 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] LATERAL
Robert Haas robertmh...@gmail.com writes: On Mon, Sep 7, 2009 at 3:43 AM, Peter Eisentrautpete...@gmx.net 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, the irony is that our current code does already infer the references - and then disallows them. Because as often as not, they're mistakes. Please don't think you're smarter than the spec here. 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] LATERAL
On Mon, Sep 7, 2009 at 7:47 PM, Tom Lanet...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Mon, Sep 7, 2009 at 3:43 AM, Peter Eisentrautpete...@gmx.net 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, the irony is that our current code does already infer the references - and then disallows them. 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 second-guessing whatever behavior the spec specifies for this construct. I'm just trying to understand it, and as far as I can tell, LATERAL() is just a piece of syntactic sugar that allows expressions within to reference FROM items at the same query level. As far as I can tell, it doesn't change the semantic of any legal queries - it just renders legal notation that otherwise would be rejected. But is my understanding correct? 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 Internet and a handful of emails from archives.postgresql.org, which seems a little thin. ...Robert -- 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] LATERAL
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 Internet and a handful of emails from archives.postgresql.org, which seems a little thin. http://wiki.postgresql.org/wiki/Developer_FAQ#Where_can_I_get_a_copy_of_the_SQL_standards.3F -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 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] LATERAL
Robert, * Robert Haas (robertmh...@gmail.com) wrote: On Mon, Sep 7, 2009 at 7:47 PM, Tom Lanet...@sss.pgh.pa.us 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 second-guessing whatever behavior the spec specifies for this construct. I'm not entirely sure you followed what Tom was getting at here. If you did, feel free to ignore me. I'm just trying to understand it, and as far as I can tell, LATERAL() is just a piece of syntactic sugar that allows expressions within to reference FROM items at the same query level. What I'm gathering is that this may be correct, though I don't know for sure. The point I think Tom was making is that even if it *is* just syntactic sugar, we don't want to allow expressions to reference FROM items at the same query level *unless* LATERAL is specified. Your earlier comments sounded like you would want to implement allowing expressions to refer to FROM items at the same query level without LATERAL being specified. 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 Internet and a handful of emails from archives.postgresql.org, which seems a little thin. You can get a 'draft' that's very close to the spec pretty easily.. Just do '??sql' in IRC sometime.. Enjoy, Stephen signature.asc Description: Digital signature
Re: [HACKERS] LATERAL
On Mon, Sep 7, 2009 at 9:12 PM, Stephen Frostsfr...@snowman.net wrote: Robert, * Robert Haas (robertmh...@gmail.com) wrote: On Mon, Sep 7, 2009 at 7:47 PM, Tom Lanet...@sss.pgh.pa.us 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 second-guessing whatever behavior the spec specifies for this construct. I'm not entirely sure you followed what Tom was getting at here. If you did, feel free to ignore me. I'm just trying to understand it, and as far as I can tell, LATERAL() is just a piece of syntactic sugar that allows expressions within to reference FROM items at the same query level. What I'm gathering is that this may be correct, though I don't know for sure. The point I think Tom was making is that even if it *is* just syntactic sugar, we don't want to allow expressions to reference FROM items at the same query level *unless* LATERAL is specified. Your earlier comments sounded like you would want to implement allowing expressions to refer to FROM items at the same query level without LATERAL being specified. Fair enough. I think I started to drift off in the direction of making that argument, but it wasn't really my point. The original point I was trying to make is that we may not need to invent any kind of new name-resolution or scoping in order to make LATERAL() work. Instead, LATERAL() can just do everything normally with the exception of not throwing the following errors when they would otherwise be thrown: subquery in FROM cannot refer to other relations of the same query level function expression in FROM cannot refer to other relations of the same query level I'm not sure if I'm right about this, but if I am, it seems likely to be a pretty straightforward change. 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 Internet and a handful of emails from archives.postgresql.org, which seems a little thin. You can get a 'draft' that's very close to the spec pretty easily.. Just do '??sql' in IRC sometime.. Thanks for the tip. ...Robert -- 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] LATERAL
* 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 you wrote. On the other hand, it sounds like the spec is pretty clear on this, and I don't feel we should violate it just because we think it's being silly on this point. The original point I was trying to make is that we may not need to invent any kind of new name-resolution or scoping in order to make LATERAL() work. Instead, LATERAL() can just do everything normally with the exception of not throwing the following errors when they would otherwise be thrown: I don't know for sure, but I do hope you're right. I'd certainly love to be able to do this in general.. There's a number of cases where I've had to do the hokey-pokey to get around our lack of ability to do this when using set-returning functions. I'm not sure if I'm right about this, but if I am, it seems likely to be a pretty straightforward change. Please continue to explore it and propose a patch. :) Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] LATERAL
On Mon, Sep 7, 2009 at 10:08 PM, Stephen Frostsfr...@snowman.net 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 requiring a keyword to tell the system that you really mean what you wrote. On the other hand, it sounds like the spec is pretty clear on this, and I don't feel we should violate it just because we think it's being silly on this point. That's pretty much where I am, too, modulo needing to better understand the aforesaid spec. The original point I was trying to make is that we may not need to invent any kind of new name-resolution or scoping in order to make LATERAL() work. Instead, LATERAL() can just do everything normally with the exception of not throwing the following errors when they would otherwise be thrown: I don't know for sure, but I do hope you're right. I'd certainly love to be able to do this in general.. There's a number of cases where I've had to do the hokey-pokey to get around our lack of ability to do this when using set-returning functions. Me too. I'm not sure if I'm right about this, but if I am, it seems likely to be a pretty straightforward change. Please continue to explore it and propose a patch. :) Yeah, that's the not-so-easy part. Gotta grok this executor stuff first before I can even think about implementing this. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] More Snow Leopard fun: multiarch problems while building plperl
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 ../../../src/backend/postgres -L/usr/local/lib -L/System/Library/Perl/5.10.0/darwin-thread-multi-2level/CORE -L../../../src/port -arch x86_64 -arch i386 -arch ppc -lperl -ldl -lm -lutil -lc -o plperl.so and complains like this: ld: warning: in ../../../src/backend/postgres, file is not of required architecture ld: warning: in plperl.o, file is not of required architecture ld: warning: in spi_internal.o, file is not of required architecture ld: warning: in SPI.o, file is not of required architecture ld: warning: in ../../../src/backend/postgres, file is not of required architecture ld: warning: in plperl.o, file is not of required architecture ld: warning: in spi_internal.o, file is not of required architecture ld: warning: in SPI.o, file is not of required architecture libperl.so, like much of the rest of the system, seems to be a 3-architecture universal binary: $ file /System/Library/Perl/lib/5.10/libperl.dylib /System/Library/Perl/lib/5.10/libperl.dylib: Mach-O universal binary with 3 architectures /System/Library/Perl/lib/5.10/libperl.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64 /System/Library/Perl/lib/5.10/libperl.dylib (for architecture i386):Mach-O dynamically linked shared library i386 /System/Library/Perl/lib/5.10/libperl.dylib (for architecture ppc7400): Mach-O dynamically linked shared library ppc which I found rather surprising because I thought Snow Leopard had yanked out all support for PPC. However, there it is. But you do *not* get 3-arch binaries out of gcc by default, and thus the warnings. The reason the linker is complaining is that it was asked to produce a 3-arch binary by the -arch x86_64 -arch i386 -arch ppc switches. It did: $ file plperl.so plperl.so: Mach-O universal binary with 3 architectures plperl.so (for architecture x86_64):Mach-O 64-bit bundle x86_64 plperl.so (for architecture i386): Mach-O bundle i386 plperl.so (for architecture ppc): Mach-O bundle ppc but I'll bet a lot of money the other two arches don't actually work. 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/CORE -lperl -ldl -lm -lutil -lc and it seems to me that it's a pretty bad idea to have this switch collection trying to override the arch(es) that Postgres is actually being built for. Does anyone have an opinion about that pro or con? Anybody have an idea about a simple way to get rid of those switches? 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] manually setting the command tag (was Re: 8.4: suppress_redundant_updates trigger vs. Upsert logic)
2009/9/8 Alvaro Herrera alvhe...@commandprompt.com: Tom Lane escribió: Alvaro Herrera alvhe...@commandprompt.com 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 example, what if there are two triggers trying to set the result, perhaps because two different commands have been generated by DO ALSO rules? We would allow the user to set a policy. This provides the mechanism for doing it. Right now there is no mechanism at all and we fail to do anything. I don't think that put it on the user's shoulders is a good solution. Is there a better idea? we should to count rows on storage level - and then (via GUC) we should to return global count or table count. ??? -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- 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] [Pgbuildfarm-members] Snow Leopard bison/flex build problem
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.212r2=2.213 ... However, I think we can work around it. AFAICS, the only reason ecpg has an extern for yyleng is because preproc.y's make_name() uses it, and there doesn't seem to be any compelling reason why that function shouldn't just do mm_strdup(yytext) instead. I've committed patches for this --- it should be safe to go back to using OS X's native flex on your buildfarm machine. 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] CREATE LIKE INCLUDING COMMENTS and STORAGES
David Fetter da...@fetter.org 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: CREATE TABLE clone_table (LIKE template_table INCLUDING STORAGES) This should probably read INCLUDING STORAGE (singular) instead of STORAGES. Thanks. I fixed it to INCLUDING STORAGE. In addition, I modified INCLUDING COMMENTS to copy comments not only on columns but also on constraints. However, comments on indexes are not copied because copied indexes are named in DefineIndex(); We don't know names of new indexes when we build a command list. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center create-including-20090908.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
