Re: Data loss when '"json_populate_recorset" with long column name

From: Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Data loss when '"json_populate_recorset" with long column name
Date: 2021-09-07 19:15:08
Message-ID: 9a7e0beb-04c0-d164-af79-60bd4a60b357@archidevsys.co.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 8/09/21 2:08 am, Tom Lane wrote:
> Julien Rouhaud <rjuju123(at)gmail(dot)com> writes:
>> On Tue, Sep 7, 2021 at 1:31 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>>> Yeah. We should try to work toward removing the limits on NAMEDATALEN
>>> for the attribute names. Easier said than done :)
>> Yes, but even if we eventually fix that my impression is that we would
>> still enforce a limit of 128 characters (or bytes) as this is the SQL
>> specification.
> Probably not. I think SQL says that's the minimum expectation; and
> even if they say it should be that exactly, there is no reason we'd
> suddenly start slavishly obeying that part of the spec after ignoring
> it for years ;-).
>
> There would still be a limit of course, but it would stem from the max
> tuple width in the associated catalog, so on the order of 7kB or so.
> (Hmm ... perhaps it'd be wise to set a limit of say a couple of kB,
> just so that the implementation limit is crisp rather than being
> a little bit different in each catalog and each release.)
>
> regards, tom lane
>
>
How about 4kB (unless there are systems for which this is too large)?

That should be easy to remember.

Cheers,
Gavin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-09-07 19:16:25 Re: Correct handling of blank/commented lines in PSQL interactive-mode history
Previous Message Andres Freund 2021-09-07 19:03:14 Re: CI/windows docker vs "am a service" autodetection on windows