From: | Jered Floyd <jered(at)permabit(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-bugs(at)postgresql(dot)org, dev-server(at)permabit(dot)com |
Subject: | Re: byteain() doesn't parse correctly |
Date: | 2001-02-07 16:18:40 |
Message-ID: | 87lmrifov3.fsf@irregular-apocalypse.permabit.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> You're right, there are multiple levels of parsing going on. The
> string-literal parser gets first crack before the type-specific
> input converter does. If you don't allow for that when counting
> backslashes etc, you'll get confused for sure.
Argh. This is really bad. This means, for example, that I can't have
NULs in my bytea, which was the whole reason I was using bytea to
begin with. Actually, maybe not.
I slighly misevaluted the way in which things are broken before. It
*does* work if I escape my escape characters (why am I reminded of
Emacs regexps?), so '\\\\' really does yield a single backslash in a
bytea. The output routine was simply re-escaping things, but lo,
octet_length() tells the truth! *cry*
Ok, good. I'm a bit concerned by backend/commands/trigger.c using
byteain() to do argument parsing, but that's not my problem right now.
--Jered
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-02-07 16:22:46 | Re: byteain() doesn't parse correctly |
Previous Message | Tom Lane | 2001-02-07 16:10:53 | Re: Re: round - timestamp bug |