Re: Selecting a constant question

Ühel kenal päeval, E, 2007-06-11 kell 22:55, kirjutas Dann Corbit:
> > -----Original Message-----
...
> > > 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.

You mean you use some kind of "Grid" inside JDBC/.NET drivers , and it
needs to know max size for a column ?

can't you replace it with a dynamically allocated Grid component, which
would also work well for other expressions, not just constants ?

> > 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.  

Is that a requirement only for "constants" or for any expression, say
"SELECT substring(reallybigblob, 1, random(1000000)) from somebigtable"
?

> 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.

by scanninc twice you find out how big the largest column _is_, not
might be .

> None of the other database vendors has any trouble reporting this information correctly.

By "this information" you mean the max possible size of data returned by
and expression ?

-----------------
Hannu