Re: Bytea/Base64 encoders for libpq - interested? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Bytea/Base64 encoders for libpq - interested?
Date
Msg-id 26723.999619271@sss.pgh.pa.us
Whole thread Raw
In response to Re: Bytea/Base64 encoders for libpq - interested?  ("Joe Conway" <joseph.conway@home.com>)
Responses Re: Bytea/Base64 encoders for libpq - interested?
Re: Bytea/Base64 encoders for libpq - interested?
List pgsql-hackers
"Joe Conway" <joseph.conway@home.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


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [PATCHES] to_char and Roman Numeral (RN) bug
Next
From: Rene Pijlman
Date:
Subject: Re: [JDBC] Troubles using German Umlauts with JDBC