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