From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Japin Li <japinli(at)hotmail(dot)com> |
Cc: | "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Inconsistent error message for varchar(n) |
Date: | 2021-11-14 19:11:30 |
Message-ID: | 2017821.1636917090@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> For comparison, it doesn't bring up the point that string values are
> constrained to 1GB; that's dealt with elsewhere. Since the limit on
> typmod is substantially more than that, I'm not sure there's much point
> in mentioning it specifically.
Oh, wait, I was not counting the zeroes in that number :-(
Tracking it a bit further, the actual typmod limit is set by this:
/*
* MaxAttrSize is a somewhat arbitrary upper limit on the declared size of
* data fields of char(n) and similar types. It need not have anything
* directly to do with the *actual* upper limit of varlena values, which
* is currently 1Gb (see TOAST structures in postgres.h). I've set it
* at 10Mb which seems like a reasonable number --- tgl 8/6/00.
*/
#define MaxAttrSize (10 * 1024 * 1024)
So maybe that's something we *should* document, though we'd have to
explain that the limit on text and unconstrained varchar is different.
regards, tom lane
(From the writing style, I suspect the "tgl" here is me not Tom Lockhart.
I'm too lazy to dig in the git history to confirm it though.)
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2021-11-14 19:13:12 | Re: Commitfest 2021-11 Patch Triage - Part 2 |
Previous Message | Tom Lane | 2021-11-14 19:00:27 | Re: Inconsistent error message for varchar(n) |