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