Re: PostgreSQL Limits: maximum number of columns in SELECT result

On Tue, 31 May 2022 at 10:49, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Dave Cramer <davecramer(at)postgres(dot)rocks> writes:
> > On Tue, 31 May 2022 at 10:16, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> We've generally felt that the existing "columns per table" limit is
> >> sufficient detail here.
>
> > ISTM that adding detail is free whereas the readers time to figure out
> why
> > and where this number came from is not.
>
> 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.
>

Sounds to me like we are discussing different sides of the same coin. On
one hand we have readers of the documentation who may be confused,
and on the other hand we have developers who run into this and have to
spend time digging into the code to figure out what's what.

For me, while I have some familiarity with the server code it takes me
quite a while to load and find what I am looking for.
Then we have the less than clear names like "resno" for which I still
haven't groked. So imagine someone who has no familiarity
with the backend code trying to figure out why 1664 is relevant when the
docs mention 1600. Surely there must be some middle ground
where we can give them some clues without having to wade through the source
code ?

Dave