Bruce Momjian writes:
> Tom Lane wrote:
>> No, the \nnn escape is built into the lexer's syntax for a string
>> literal (see backend/parser/scan.l),
> Should we rethink this for SQL standard strings?
We already have: \ isn't an escape anymore when
standard_conforming_strings is true.
Tom Lane wrote:
> "Michael Artz" <[EMAIL PROTECTED]> writes:
> > What ig going on behind the scenes? Does it first get converted to text and
> > then on to bytea?
>
> No, the \nnn escape is built into the lexer's syntax for a string
> literal (see backend/parser/scan.l), and only after that does
"Michael Artz" <[EMAIL PROTECTED]> writes:
> What ig going on behind the scenes? Does it first get converted to text and
> then on to bytea?
No, the \nnn escape is built into the lexer's syntax for a string
literal (see backend/parser/scan.l), and only after that does the string
get fed to bytea'
Eh, I'll just convert it all to octal, I just thought that I could get away without any middleman.What ig going on behind the scenes? Does it first get converted to text and then on to bytea? Would an explicit cast get around this (perhaps with associated UDF)?
-MikeOn 5/16/06, Tom Lane <[EMAIL P
"Michael Artz" <[EMAIL PROTECTED]> writes:
> Silly little question, but is there something to input/output hex
> escaped data into a bytea, ala
PQescapeBytea, perhaps? The way you are doing it has multiple problems.
regards, tom lane
---(end of br
Silly little question, but is there something to input/output hex
escaped data into a bytea, ala
CREATE TABLE a (lob BYTEA);
INSERT into a (lob) VALUES ('\x01\x02\x00\x03\x04');
INSERT into a (lob) VALUES ('\x01\x00\x02\x00\x03\x04');
It seems to work (doesn't error), but when selecting the data
