Re: Inconsistent error message for varchar(n) - Mailing list pgsql-hackers

From Dagfinn Ilmari Mannsåker
Subject Re: Inconsistent error message for varchar(n)
Date
Msg-id 87r1bipiyu.fsf@wibble.ilmari.org
Whole thread Raw
In response to Re: Inconsistent error message for varchar(n)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:

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

I was bored, and found this:

commit 022417740094620880488dd9b04fbb96ff11694b
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   2000-08-07 20:16:13 +0000

    TOAST mop-up work: update comments for tuple-size-related symbols such
    as MaxHeapAttributeNumber.  Increase MaxAttrSize to something more
    reasonable (given what it's used for, namely checking char(n) declarations,
    I didn't make it the full 1G that it could theoretically be --- 10Mb
    seemed a more reasonable number).  Improve calculation of MaxTupleSize.

which added the above comment and changed MaxAttrSize:

-#define MaxAttrSize        (MaxTupleSize - MAXALIGN(sizeof(HeapTupleHeaderData)))
+#define MaxAttrSize        (10 * 1024 * 1024)
  
- ilmari



pgsql-hackers by date:

Previous
From: Victor Spirin
Date:
Subject: Re: Atomic rename feature for Windows.
Next
From: Tom Lane
Date:
Subject: Re: JIT doing duplicative optimization?