Re: Inconsistent error message for varchar(n)

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

In response to

Responses

Browse pgsql-hackers by date

  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)