>
> 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 o
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 fi
* 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 cou
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 mak
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:
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 comm
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 wit
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 s
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
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.
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 s
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
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).
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?
--
P
Bruce Momjian 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.
* For equal-length p
Tom Lane wrote:
> Bruce Momjian 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
> > **
Bruce Momjian 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
> ***
> *** 193,199
> x
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 Rober
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 a
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 a
Neil Conway wrote:
> Bruce Momjian wrote:
> > We need to preceed our function names with pg_ for cases like this where
> > we are supplying pg-specific behavior.
>
> We do? I'm not sure I can see much of a consistent naming convention for
> functions like these: version(), obj_description(), has_
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 simpl
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
Tom Lane wrote:
I would also expect that matching is by SQLSTATE, that is if I write
DECLARE foo EXCEPTION = '12345';
...
RAISE ERROR foo, ...;
BTW, is there any value in a separate "EXCEPTION" type? ISTM that an
exception is just a SQLSTATE, which is in turn just a st
24 matches
Mail list logo
