Re: Patch to document base64 encoding - Mailing list pgsql-hackers

From Karl O. Pinc
Subject Re: Patch to document base64 encoding
Date
Msg-id 20190802093253.1ac77498@slate.karlpinc.com
Whole thread Raw
In response to Re: Patch to document base64 encoding  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: Patch to document base64 encoding  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Patch to document base64 encoding  (Chapman Flack <chap@anastigmatix.net>)
List pgsql-hackers
On Tue, 30 Jul 2019 23:44:49 +0200 (CEST)
Fabien COELHO <coelho@cri.ensmp.fr> wrote:

> Personnaly, I'd be ok with having a separate "conversion function"
> table, and also with Tom suggestion to have string functions with
> "only simple string" functions, and if any binary appears it is moved
> into the binary section.

I'll make a "conversion function" table and put it in the binary
section.

But I'm not happy with putting any function that works with
bytea into the binary string section.  This would mean moving,
say, length() out of the regular string section.  There's a
lot of functions that work on both string and bytea inputs
and most (not all, see below) are functions that people
typically associate with string data.

What I think I'd like to do is add a column to the table
in the string section that says whether or not the function
works with both string and bytea.  The result would be:

The hash functions (md5(), sha256(), etc.) would move
to the string section, because they work on both strings
and binary data.  So the binary function table would
considerably shorten.

There would be a new table for conversions between
bytea and string (both directions).  This would
be placed in the binary string section.

So the binary string section would be "just simple bytea", plus
conversion functions.  Kind of the opposite of Tom's
suggestion.

Please let me know what you think.  Thanks.

Regards,

Karl <kop@karlpinc.com>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Recent failures in IsolationCheck deadlock-hard
Next
From: Tomas Vondra
Date:
Subject: Re: pglz performance