Skip site navigation (1) Skip section navigation (2)

Re: Bytea/Base64 encoders for libpq - interested?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Joe Conway" <joseph(dot)conway(at)home(dot)com>
Cc: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Karel Zak" <zakkr(at)zf(dot)jcu(dot)cz>, "Joerg Hessdoerfer" <Joerg(dot)Hessdoerfer(at)sea-gmbh(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Bytea/Base64 encoders for libpq - interested?
Date: 2001-09-04 16:01:11
Message-ID: 26723.999619271@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
"Joe Conway" <joseph(dot)conway(at)home(dot)com> writes:
> You're right, as usual (I was tired when I wrote this last night ;). But I
> think we have to escape/unescape both null and '\', don't we?

Yeah, you're right.  My turn to have not thought hard enough.

> I agree that it would be better to *not* allow implicit coercions. Given
> that, any preferences on function names? Are text_to_bytea() and
> bytea_to_text() too ugly?

They're pretty ugly, but more importantly they're only suitable if we
have exactly one conversion function each way.  If we have two, what
will we call the second one?

I think it's okay to let the argument type be implicit in the function
argument list.  Something like text_escaped(bytea) and text_direct(bytea)
(with inverses bytea_escaped(text) and bytea_direct(text)) might do.
I'm not totally happy with "direct" to suggest minimum escaping, though.
Better ideas anyone?

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: RyanDate: 2001-09-04 16:32:58
Subject: Re: Toast, Text, blob bytea Huh?
Previous:From: Joe ConwayDate: 2001-09-04 15:46:44
Subject: Re: Bytea/Base64 encoders for libpq - interested?

pgsql-patches by date

Next:From: Bruce MomjianDate: 2001-09-04 16:35:40
Subject: Re: Patch for pl/tcl Tcl_ExternalToUtf and Tcl_UtfToExternal
Previous:From: Joe ConwayDate: 2001-09-04 15:46:44
Subject: Re: Bytea/Base64 encoders for libpq - interested?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group