Bruce Momjian <[EMAIL PROTECTED]> writes:
> Has this been resolved?
Peter applied his patch, but I am planning to also change addlit to not
require null termination, because I believe we'll get bit again if we
don't.
regards, tom lane
---(end of b
Has this been resolved?
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Tom Lane writes:
> >> I don't follow. xddouble can only expand to two quote marks, so how
> >> does it matter which one we use as the result?
>
> > addlit() expects the first argument to be null-terminated and implicit
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> I don't follow. xddouble can only expand to two quote marks, so how
>> does it matter which one we use as the result?
> addlit() expects the first argument to be null-terminated and implicitly
> uses that null byte at the end of
Tom Lane writes:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > A bug indeed.
>
> > {xddouble} {
> > - addlit(yytext, yyleng-1);
> > + addlit(yytext+1, yyleng-1);
> > }
>
> I don't fol
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> A bug indeed.
> {xddouble} {
> - addlit(yytext, yyleng-1);
> + addlit(yytext+1, yyleng-1);
> }
I don't follow. xddouble can only expand to
Florian Weimer writes:
> In addition, there seems to be a bug in the treatment of "" escapes in
> identifiers. 'SELECT ;' yields the error message 'Attribute '""'
> not found ' (not '"'!) or even 'Attribute '""\' not found', depending
> on the queries executed before.
A bug indeed.
RCS file
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>
> > OK, can you supply an updated patch?
>
> Yes, I'm going to update it. Shall I post it here?
Sure, or patches list.
> Could anybody have a look at the parser issue?
I am unsure how it is supposed to behave. Comments? Does the standard
say an
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, can you supply an updated patch?
Yes, I'm going to update it. Shall I post it here?
Could anybody have a look at the parser issue?
--
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart http://cert.uni-stuttgar
OK, can you supply an updated patch?
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
>
> > Florian Weimer writes:
> >
> > > The first version escaped ' with ''. I changed it when I noticed that
> > > if \' is used instead, the same function can be used for strings
> > > ('...') and identifier
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Florian Weimer writes:
>
> > The first version escaped ' with ''. I changed it when I noticed that
> > if \' is used instead, the same function can be used for strings
> > ('...') and identifiers ("...").
>
> Last time I checked (15 seconds ago),
Florian Weimer writes:
> The first version escaped ' with ''. I changed it when I noticed that
> if \' is used instead, the same function can be used for strings
> ('...') and identifiers ("...").
Last time I checked (15 seconds ago), you could not escape " with \ in
PostgreSQL. The identifer
Christopher Masto <[EMAIL PROTECTED]> writes:
> I only have one issue - the SQL standard seems to support the use
> of '' to escape a single quote, but not \'. Though PostgreSQL has
> an extended notion of character string literals, I think that the
> usual policy of using the standard interface
On Wed, Aug 22, 2001 at 05:16:44PM +, Florian Weimer wrote:
> We therefore suggest that a string escaping function is included in a
> future version of PostgreSQL and libpq. A sample implementation is
> provided below, along with documentation.
I use Perl, which (through DBD::Pg) has a "quot
13 matches
Mail list logo
