Re: [PATCH] by request: base64 for bytea

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alex Pilosov <alex(at)pilosoft(dot)com>, Marko Kreen <marko(at)l-t(dot)ee>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] by request: base64 for bytea
Date: 2001-06-24 21:05:54
Message-ID: 200106242105.f5OL5sh28859@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Alex Pilosov <alex(at)pilosoft(dot)com> writes:
> > Function to cast bytea as text, I think, should do proper checking that
> > input did not contain nulls, and return text data back.
>
> That is most definitely not good enough. In MULTIBYTE installations
> you'd have to also check that there were no illegal multibyte sequences.
>
> The whole approach seems misguided to me anyway. bytea isn't equivalent
> to text and conversion functions based on providing incomplete binary
> equivalence are fundamentally wrong. hex or base64 encode/decode
> functions seem like reasonable conversion paths, or you could provide
> a function that mimics the existing I/O conversions for bytea, ugly as
> they are.

He can create an output function just to text, and varchar, etc will work
OK, right?

I think the main issue is that char(), varchar(), text all input/output
strings of the same format while bytea has special backslash handling
for binary/null values.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2001-06-24 21:08:10 Re: Why would this use 600Meg of VM?
Previous Message Tom Lane 2001-06-24 15:26:27 Re: [PATCH] by request: base64 for bytea