Re: [PATCHES] hash join: probe both inputs first

2005-06-15 Thread Neil Conway
Neil Conway wrote: Per earlier discussion on pgsql-hackers[1], this patch changes the implementation of hash join to attempt to avoid redundant work if either of the join relations are empty. Applied. -Neil ---(end of broadcast)--- TIP 6: Have

Re: [PATCHES] user's exception PL/pgSQL

2005-06-15 Thread Pavel Stehule
Hello, the name of exception's variable I use as exception's name. Attached patch work, but miss documentations, regress, .. BTW, is there any value in a separate EXCEPTION type? ISTM that an exception is just a SQLSTATE, which is in turn just a string. A separate exception type does simplify

Re: [PATCHES] pg_autovacuum patch to display db name in log file is broken

2005-06-15 Thread Bruce Momjian
Patch applied. Thanks. --- Cosimo Streppone wrote: Hi Bruce, it seems that the quick fix I submitted about pg_autovacuum to show ANALYZE dbname.tablename in logs is broken. In fact, looking at the cvs diff at:

Re: [PATCHES] plpgsql raise - parameters can be expressions

2005-06-15 Thread Tom Lane
Neil Conway [EMAIL PROTECTED] writes: BTW, is there any value in a separate EXCEPTION type? ISTM that an exception is just a SQLSTATE, which is in turn just a string. A separate exception type does simplify the parsing of RAISE, but I wonder if it would be useful to be able to also allow

[PATCHES] Lexer patch question

2005-06-15 Thread Bruce Momjian
I am confused why the following change Tom made to scan.l works. Isn't that 'x' required so xqescape doesn't match '\x'? -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13

Re: [PATCHES] Lexer patch question

2005-06-15 Thread Tom Lane
Bruce Momjian pgman@candle.pha.pa.us writes: I am confused why the following change Tom made to scan.l works. Isn't that 'x' required so xqescape doesn't match '\x'? *** scan.l2 Jun 2005 01:23:08 - 1.123 --- scan.l2 Jun 2005 17:45:17 - 1.124 *** ***

Re: [PATCHES] Lexer patch question

2005-06-15 Thread Bruce Momjian
Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: I am confused why the following change Tom made to scan.l works. Isn't that 'x' required so xqescape doesn't match '\x'? *** scan.l 2 Jun 2005 01:23:08 - 1.123 --- scan.l 2 Jun 2005 17:45:17 - 1.124

Re: [PATCHES] Lexer patch question

2005-06-15 Thread Tom Lane
Bruce Momjian pgman@candle.pha.pa.us writes: Oh, I didn't realize lexers would choose the longer token when given multiple options. See lines 95-100 in scan.l: * OK, here is a short description of lex/flex rules behavior. * The longest pattern which matches an input string is always chosen.

Re: [PATCHES] Add PG version number to NLS files

2005-06-15 Thread Peter Eisentraut
Bruce Momjian wrote: I have developed the following patch which adds PG_VERSION to the end of language-specific file names. In my mind, that would only make sense if we added the version number to all program binaries as well (which we do not, of course). Otherwise, what's the point? --

Re: [PATCHES] Add PG version number to NLS files

2005-06-15 Thread Bruce Momjian
Peter Eisentraut wrote: Bruce Momjian wrote: I have developed the following patch which adds PG_VERSION to the end of language-specific file names. In my mind, that would only make sense if we added the version number to all program binaries as well (which we do not, of course).

Re: [PATCHES] Add PG version number to NLS files

2005-06-15 Thread Bruce Momjian
Peter Eisentraut wrote: Bruce Momjian wrote: The 'bind' calles in the binaries are going to look for the proper version. Does that help, or is libpq the only thing we need to handle? Shared libraries have their version number embedded in the file name for the explicit purpose of

Re: [PATCHES] Add PG version number to NLS files

2005-06-15 Thread Peter Eisentraut
Bruce Momjian wrote: The 'bind' calles in the binaries are going to look for the proper version. Does that help, or is libpq the only thing we need to handle? Shared libraries have their version number embedded in the file name for the explicit purpose of installing more than one version

Re: [PATCHES] [COMMITTERS] pgsql: Add BETWEEN SYMMETRIC.

2005-06-15 Thread Bruce Momjian
OK, patch attached and applied. Thanks. --- Pavel Stehule wrote: Hello SYMMETRIC and ASYMMETRIC have to be reserved words. http://archives.postgresql.org/pgsql-hackers/2002-04/msg00094.php I lost my patch. Can

[PATCHES] Escape handling in strings

2005-06-15 Thread Bruce Momjian
A summary of my proposal to add a new E'' string for escape and have non-E escapes not handle backslashes specially is at: http://candle.pha.pa.us/cgi-bin/pgescape Attached is a patch that emits warnings for \ and \', perhaps for 8.1. The change to scan.l is the place this is done. The

Re: [PATCHES] Escape handling in strings

2005-06-15 Thread Christopher Kings-Lynne
I'm still really iffy about this. I think it will really hurt pgsql due to backward compatibility :( (If I'm understanding how the proposed change works...) Chris Bruce Momjian wrote: A summary of my proposal to add a new E'' string for escape and have non-E escapes not handle backslashes

Re: [PATCHES] Escape handling in strings

2005-06-15 Thread Bruce Momjian
Christopher Kings-Lynne wrote: I'm still really iffy about this. I think it will really hurt pgsql due to backward compatibility :( (If I'm understanding how the proposed change works...) Yep, you probably are. The hurt is backward compatibility, but the gain is greater portability with

Re: [PATCHES] Escape handling in strings

2005-06-15 Thread Christopher Kings-Lynne
Yep, you probably are. The hurt is backward compatibility, but the gain is greater portability with other database systems. It's just going to break millions of PHP scripts :( Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe

Re: [PATCHES] Escape handling in strings

2005-06-15 Thread Bruce Momjian
Christopher Kings-Lynne wrote: Yep, you probably are. The hurt is backward compatibility, but the gain is greater portability with other database systems. It's just going to break millions of PHP scripts :( Let me give you a little longer answer. Right now we have this TODO item:

Re: [PATCHES] Escape handling in strings

2005-06-15 Thread Bruce Momjian
Sorry, one more thing. :-( Let me add that I am not 100% sold on the idea either, but using the logic I outlined, I don't see how we can continue to do nothing about this issue, and I am afraid delay will only make an inevitable fix harder. Maybe we will have to wait 2-3 years before we can

Re: [PATCHES] Escape handling in strings

2005-06-15 Thread Christopher Kings-Lynne
* Allow backslash handling in quoted strings to be disabled for portability The use of C-style backslashes (.e.g. \n, \r) in quoted strings is not SQL-spec compliant, so allow such handling to be disabled. However, disabling backslashes

Re: [PATCHES] Escape handling in strings

2005-06-15 Thread Rod Taylor
On Wed, 2005-06-15 at 23:13 -0400, Bruce Momjian wrote: Sorry, one more thing. :-( Let me add that I am not 100% sold on the idea either, but using the logic I outlined, I don't see how we can continue to do nothing about this issue, and I am afraid delay will only make an inevitable fix

Re: [PATCHES] Escape handling in strings

2005-06-15 Thread Pavel Stehule
Why not compromise? Allow ONLY \' in normal strings? That'd deal with the majority of compatibility issues. Or, like you say, make it a GUC :( Chris what is wrong on GUC? Pavel ---(end of broadcast)--- TIP 6: Have you searched our