Re: Data loss when '"json_populate_recorset" with long column name
От | Gavin Flower |
---|---|
Тема | Re: Data loss when '"json_populate_recorset" with long column name |
Дата | |
Msg-id | 9a7e0beb-04c0-d164-af79-60bd4a60b357@archidevsys.co.nz обсуждение исходный текст |
Ответ на | Re: Data loss when '"json_populate_recorset" with long column name (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 8/09/21 2:08 am, Tom Lane wrote: > Julien Rouhaud <rjuju123@gmail.com> writes: >> On Tue, Sep 7, 2021 at 1:31 PM Michael Paquier <michael@paquier.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
В списке pgsql-hackers по дате отправления: