Re: Patch to document base64 encoding

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Karl O(dot) Pinc" <kop(at)karlpinc(dot)com>
Cc: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>
Subject: Re: Patch to document base64 encoding
Date: 2019-08-02 14:44:43
Message-ID: 1231.1564757083@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Karl O. Pinc" <kop(at)karlpinc(dot)com> writes:
> 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.

Well, there are two different length() functions --- length(text)
and length(bytea) are entirely different things, they don't even
measure in the same units. I think documenting them separately
is the right thing to do. I don't really have a problem with
repeating the entries for other functions that exist in both
text and bytea variants, either. There aren't that many.

> 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.

Meh. Seems like what that would mostly do is ensure that
neither page is understandable on its own.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chapman Flack 2019-08-02 15:00:42 Re: Patch to document base64 encoding
Previous Message Tomas Vondra 2019-08-02 14:43:45 Re: pglz performance