Re: Selecting a constant question

> -----Original Message-----
> From: Hannu Krosing [mailto:hannu(at)skype(dot)net]
> 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(at)postgresql(dot)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.