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

From Joe Conway
Subject Re: Bytea/Base64 encoders for libpq - interested?
Date
Msg-id 00dc01c13558$cd6ad790$0705a8c0@jecw2k1
Whole thread Raw
In response to Re: Bytea/Base64 encoders for libpq - interested?  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Bytea/Base64 encoders for libpq - interested?
Re: Bytea/Base64 encoders for libpq - interested?
List pgsql-hackers
> Ugh ... if the conversion functions are not inverses then I think they
> lose much of their value.  I could see doing either of these:
>
> 1. Conversion functions based on byteaout/byteain.
>
> 2. Bytea to text escapes *only* null bytes, text to bytea treats only
> "\0" as an escape sequence.
>
> Or maybe both, with two pairs of conversion functions.
>
> In any case, we have to decide whether these coercion functions should
> be named after the types --- ie, should they be made invokable as
> implicit coercions?  I'm dubious that that's a good idea; if we do it
> then all sorts of textual operations will suddenly be allowed for bytea
> without any explicit conversion, which is likely to do more harm than
> good.  The reason for having a separate bytea type is exactly so that
> you *can't* apply text ops to it without thinking.
>
> regards, tom lane

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?

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?

-- Joe





pgsql-hackers by date:

Previous
From: Karel Zak
Date:
Subject: Re: [PATCHES] to_char and Roman Numeral (RN) bug
Next
From: Bruce Momjian
Date:
Subject: Re: [PATCHES] to_char and Roman Numeral (RN) bug