On Tue, 31 May 2022 at 12:00, Vladimir Sitnikov
wrote:
>
> Please, do not suggest me avoid 65535 parameters. What I wanted was just to
> test that the driver was able to handle 65535 parameters.
I don't think we have regression tests to cover things at these
limits, that might be worth adding
David Rowley writes:
> Maybe "columns per result set" would have been a better title for consistency.
I can't quite put my finger on why, but that wording seems odd to me,
even though "columns per table" is natural enough. "In a" reads much
better here IMO. Anyway, I see you committed it that
On Wed, 1 Jun 2022 at 12:42, Tom Lane wrote:
>
> David Rowley writes:
> > I've adjusted the patch to use the wording proposed by Alvaro. See attached.
>
> Should we also change the adjacent item to "columns in a table",
> for consistency of wording? Not sure though, because s/per/in a/
>
On 1/06/22 12:42, Tom Lane wrote:
David Rowley writes:
I've adjusted the patch to use the wording proposed by Alvaro. See attached.
Should we also change the adjacent item to "columns in a table",
for consistency of wording? Not sure though, because s/per/in a/
throughout the list doesn't
David Rowley writes:
> I've adjusted the patch to use the wording proposed by Alvaro. See attached.
Should we also change the adjacent item to "columns in a table",
for consistency of wording? Not sure though, because s/per/in a/
throughout the list doesn't seem like it'd be an improvement.
On Tue, 31 May 2022 at 20:33, David Rowley wrote:
> On Wed, 1 Jun 2022 at 07:08, Dave Cramer
> wrote:
> >
> > On Tue, 31 May 2022 at 14:51, Tom Lane wrote:
> >>
> >> Alvaro Herrera writes:
> >> > I think it's reasonable to have two adjacent rows in the table for
> these
> >> > two closely
On Wed, 1 Jun 2022 at 07:08, Dave Cramer wrote:
>
> On Tue, 31 May 2022 at 14:51, Tom Lane wrote:
>>
>> Alvaro Herrera writes:
>> > 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
On Tue, May 31, 2022 at 01:22:44PM -0400, Dave Cramer wrote:
>
>
> On Tue, 31 May 2022 at 10:49, Tom Lane wrote:
>
> Dave Cramer writes:
> > On Tue, 31 May 2022 at 10:16, Tom Lane wrote:
> >> We've generally felt that the existing "columns per table" limit is
> >> sufficient
On Tue, 31 May 2022 at 14:51, Tom Lane wrote:
> Alvaro Herrera writes:
> > 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
Alvaro Herrera writes:
> 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
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
On Tue, 31 May 2022 at 10:49, Tom Lane wrote:
> Dave Cramer writes:
> > On Tue, 31 May 2022 at 10:16, Tom Lane 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
>ost readers are going to spend more time
>wondering what the difference is between "columns per table" and "columns
>per tuple"
"tuple" is already mentioned 10 times on "limits" page, so adding "columns
per tuple" is not really obscure.
The comment could be like "for instance, max number of
Dave Cramer writes:
> On Tue, 31 May 2022 at 10:16, Tom Lane 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
On Tue, 31 May 2022 at 10:16, Tom Lane wrote:
> Amul Sul writes:
> > On Tue, May 31, 2022 at 12:46 PM Vladimir Sitnikov
> > wrote:
> >> I suggest that the limit of "1664 columns per tuple" (or whatever is
> the right term) should be added
> >> to the list at
Amul Sul writes:
> On Tue, May 31, 2022 at 12:46 PM Vladimir Sitnikov
> wrote:
>> I suggest that the limit of "1664 columns per tuple" (or whatever is the
>> right term) should be added
>> to the list at https://www.postgresql.org/docs/current/limits.html e.g.
>> after "columns per table".
>
>
>
>
> On Tue, 31 May 2022 at 09:56, Amul Sul wrote:
>
>> On Tue, May 31, 2022 at 12:46 PM Vladimir Sitnikov
>> wrote:
>> >
>> > Hi,
>> >
>> > Today I hit "ERROR: target lists can have at most 1664 entries", and I
>> was surprised the limit was not documented.
>> >
>> > I suggest that the
On Tue, 31 May 2022 at 09:56, Amul Sul wrote:
> On Tue, May 31, 2022 at 12:46 PM Vladimir Sitnikov
> wrote:
> >
> > Hi,
> >
> > Today I hit "ERROR: target lists can have at most 1664 entries", and I
> was surprised the limit was not documented.
> >
> > I suggest that the limit of "1664 columns
On Tue, May 31, 2022 at 12:46 PM Vladimir Sitnikov
wrote:
>
> Hi,
>
> Today I hit "ERROR: target lists can have at most 1664 entries", and I was
> surprised the limit was not documented.
>
> I suggest that the limit of "1664 columns per tuple" (or whatever is the
> right term) should be added
>
Hi,
Today I hit "ERROR: target lists can have at most 1664 entries", and I was
surprised the limit was not documented.
I suggest that the limit of "1664 columns per tuple" (or whatever is the
right term) should be added
to the list at https://www.postgresql.org/docs/current/limits.html e.g.
20 matches
Mail list logo
