Ü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
---------------------------(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
match
