> -----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; [EMAIL PROTECTED]
> 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.


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:    http://lists.mysql.com/[EMAIL PROTECTED]

Reply via email to