> -----Original Message----- > From: Hannu Krosing [mailto:[EMAIL PROTECTED] > Sent: Monday, June 11, 2007 10:43 PM > To: Larry McGhaw > Cc: Tom Lane; Alvaro Herrera; Dann Corbit; Gregory Stark; Martijn van > Oosterhout; pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Selecting a constant question > > Ühel kenal päeval, E, 2007-06-11 kell 22:11, kirjutas Larry McGhaw: > > As far as I am aware these statements are true. If you have a > > specific example you could provide to the contrary that would be > > interesting. > > > > Even if there are such conditions it does not change the fact that > > libpq and/or postgresql is deficient in this area. > > > > For any query, the database should be capable of describing the > > metadata for the columns, which includes > > 1) the column type > > and > > 2) the column maximum length. > > > > This is such a basic database interface principle that I very > > disappointed that someone has not recognized this and simply said " > > yes, we see the issue we will work on it". > > > > Again, *all* other major relational databases do this ... even blob > > fields have a maximum length reported from the database. > > > > I hope someone who truly understands database interfaces will read > > this thread and address the issue. > > For now we will have to "special case" postgres in our application > > until it is addressed. > > > > or redesign your application so that it allocates memory as needed and > won't waste client memory by allocating maximum possible amount for each > and every grid cell weather needed or not ;) > > As I understand from this discussion you are writing some kind of > middleware (i.e. tools), and I'd expect toolmakers to do the right > thing.
In this case the middleware is: ODBC/JDBC/OLEDB/.NET data drivers for PostgreSQL. There are other related tools, but the above is the product for which the bug needs corrected. > allocating as much as possibly ever needed is something that would be > excusable in quick-n-dirty end user application, but not in a tool. It's a requirement of the ODBC/JDBC/OLEDB/.NET specifications. I suppose we could scan the table twice to figure out how large a column might be, but that would make the PostgreSQL driver run at 1/2 speed. Not a very appetizing solution. None of the other database vendors has any trouble reporting this information correctly. ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq