Ü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 ?


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not

Reply via email to