From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Larry McGhaw" <lmcghaw(at)connx(dot)com> |
Cc: | "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Dann Corbit" <DCorbit(at)connx(dot)com>, "Gregory Stark" <stark(at)enterprisedb(dot)com>, "Martijn van Oosterhout" <kleptog(at)svana(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Selecting a constant question |
Date: | 2007-06-12 00:32:21 |
Message-ID: | 27842.1181608341@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Larry McGhaw" <lmcghaw(at)connx(dot)com> writes:
> I think perhaps we have lost sight of the main issue:
> 1) libpq can properly describe the maximum internal data size of any
> numeric or char column in a table via Pqfsize
> 2) libpq can properly describe the maximum internal data size of any
> varchar column via Pqfmod
> 3) libpq can properly describe the maximum internal data size of any
> numeric constant in a SQL statement via Pqfsize
None of the above statements are actually true, at least not when you
take off your blinders and note the existence of unconstrained-width
numeric and text columns.
> The database *knows* this size of the char constant (obviously),
No, what it knows (and reports) is type information. There are a small
number of datatypes where you can infer a maximum width from knowledge
of the datatype. There are many others where you can't set an upper
bound from this knowledge --- at least not a usefully tight one.
Anyway, if we were to cast those constants to something other than
unknown, it would be text, not varchar, and you'd still have the same
issue.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Dann Corbit | 2007-06-12 00:33:11 | Re: Got no response last time on setsockopt post, so I thought I would reiterate. |
Previous Message | Dann Corbit | 2007-06-12 00:24:42 | Re: Selecting a constant question |