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
Example: select '123' from <any table>
This is clearly a bug or serious oversight in libpq that should be
The database *knows* this size of the char constant (obviously), and
should report the size via a metadata call, as all other relational
From: Alvaro Herrera [mailto:[EMAIL PROTECTED]
Sent: Monday, June 11, 2007 3:44 PM
To: Dann Corbit
Cc: Tom Lane; Gregory Stark; Martijn van Oosterhout;
firstname.lastname@example.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.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly