From: | Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org, Rob Gansevles <rgansevles(at)gmail(dot)com> |
Subject: | Re: Maximum size for char or varchar with limit |
Date: | 2010-12-08 17:12:05 |
Message-ID: | 4CFFBC65.8090105@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 12/08/2010 09:05 AM, Tom Lane wrote:
> Adrian Klaver<adrian(dot)klaver(at)gmail(dot)com> writes:
>> On 12/08/2010 08:04 AM, Tom Lane wrote:
>>> The rationale for having a limit of this sort is (a) we *don't* want
>>> the upper limit of declarable length to be encoding-dependent; and
>>> (b) if you are trying to declare an upper limit that's got more than a
>>> few digits in it, you almost certainly ought to not be declaring a limit
>>> at all.ion
>
>> Well that explains it :) Would it be possible to change the below
>> section in the docs to state that the declared max value of n is limited
>> to a max string size of 10Mb?
>
> I don't really see any point in that. The value is meant to be an order
> of magnitude or so more than anything that's sane according to point (b).
> If you think you need to know what it is, you're already doing it wrong.
>
> regards, tom lane
Well the determination of sanity is often in the eye of the beholder and
it would be nice to know where the line is. At any rate the answer is
the archives now, so I know where to get it.
--
Adrian Klaver
adrian(dot)klaver(at)gmail(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Vick Khera | 2010-12-08 17:18:05 | Re: SELECT is immediate but the UPDATE takes forever |
Previous Message | Tom Lane | 2010-12-08 17:05:18 | Re: Maximum size for char or varchar with limit |