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
4) libpq **cannot** describe the maximum internal data size of a char or
varchar constant!
Example: select '123' from <any table>
This is clearly a bug or serious oversight in libpq that should be
addressed.
The database *knows* this size of the char constant (obviously), and
should report the size via a metadata call, as all other relational
databases do.
Thanks
lm
-----Original Message-----
From: Alvaro Herrera [mailto:alvherre@commandprompt.com]
Sent: Monday, June 11, 2007 3:44 PM
To: Dann Corbit
Cc: Tom Lane; Gregory Stark; Martijn van Oosterhout;
pgsql-hackers@postgresql.org; Larry McGhaw
Subject: Re: [HACKERS] Selecting a constant question
Dann Corbit wrote:
> If the server bound the data as UNICODE, then it will tell me
> UNICODE(3). I know how big this will be.
>
> In the worst case scenario it will fit in 3*4 = 12 bytes.
>
> If the server is built without UNICODE enabled, then it will
> definitely fit in 3 bytes.
Unless it's some other multibyte encoding. And nowadays, the server is
always "unicode enabled". The stuff sent down the wire is unicode or
not depending on a configuration parameter.
--
Alvaro Herrera
http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support