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:[EMAIL PROTECTED] 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 ---------------------------(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
