From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Timur V(dot) Irmatov" <itvthor(at)sdf(dot)lonestar(dot)org> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: BYTEA |
Date: | 2002-09-20 14:43:48 |
Message-ID: | 16192.1032533028@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Timur V. Irmatov" <itvthor(at)sdf(dot)lonestar(dot)org> writes:
> I'd like to hear background explanation of why strings used as bytea
> literals pass two phases of parsing?
Because there is no other alternative: the parser is not aware when it's
scanning a SQL command whether a string literal will end up being taken
as a BYTEA value or not.
One possibility for inserting BYTEA without quite so much quoting is to
insert via COPY IN instead of INSERT. This is not a complete solution
however, since you still have to beware of COPY's escaping rules for
newlines and tabs.
If you really don't want to be bothered, you could think about defining
a function
create function myinsert (..., bytea, ...) as '
INSERT INTO mytable VALUES($1,$2,...)' language SQL;
and then invoking this function via the "fastpath" interface. The
fastpath stuff is pretty ugly but it would let you send raw binary
data.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-09-20 15:19:30 | Re: timestamp parse error |
Previous Message | Stephan Szabo | 2002-09-20 14:38:25 | Re: timestamp parse error |