| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Dave Cramer <davecramer(at)postgres(dot)rocks>, Amul Sul <sulamul(at)gmail(dot)com>, Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: PostgreSQL Limits: maximum number of columns in SELECT result |
| Date: | 2022-05-31 18:15:14 |
| Message-ID: | 202205311815.34mrqrz3pwfr@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2022-May-31, Tom Lane wrote:
> Detail is far from "free". Most readers are going to spend more time
> wondering what the difference is between "columns per table" and "columns
> per tuple", and which limit applies when, than they are going to save by
> having the docs present them with two inconsistent numbers.
I think it's reasonable to have two adjacent rows in the table for these
two closely related things, but rather than "columns per tuple" I would
label the second one "columns in a result set". This is easy enough to
understand and to differentiate from the other limit.
(Replacing "in a" with "per" sounds OK to me but less natural, not sure
why.)
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"The Gord often wonders why people threaten never to come back after they've
been told never to return" (www.actsofgord.com)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2022-05-31 18:21:28 | Re: ParseTzFile doesn't FreeFile on error |
| Previous Message | Dave Cramer | 2022-05-31 17:22:44 | Re: PostgreSQL Limits: maximum number of columns in SELECT result |