> -----Original Message-----
> From: Alvaro Herrera [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 11, 2007 3:16 PM
> To: Dann Corbit
> Cc: Gregory Stark; Martijn van Oosterhout;
pgsql-hackers@postgresql.org;
> Larry McGhaw
> Subject: Re: [HACKERS] Selecting a constant question
>
> Dann Corbit wrote:
>
> > > "Dann Corbit" <[EMAIL PROTECTED]> writes:
> > >
> > > In fact psql needs it and implements this. It has to skim through
the
> > > entire
> > > result set to calculate the column widths. It's quite a lot of
work
> > but
> > > the
> > > server is in no better position to do it than psql.
> >
> > Reading the data twice sounds a little painful. What if there are
30
> > million rows?
>
> You get an "out of memory" error.
>
> > > On the contrary the server is missing quite a bit of information
of
> > > how you intend to display the information. Do you need the number
of
> > > bytes or characters? Are all the characters the same width in your
> > > display system? What about currency symbols? Do you intend to
> > > reverse any quoting or just display backslashes?
> >
> > Giving me the information about the data type will be enough. As an
> > example, in this case we have varchar data. If the server should be
so
> > kind as to report varchar(1) for '1' or varchar(3) for '123' then I
> > would not have any difficulty binding the data to a grid.
>
> Oh, you have the length information for each datum all right. It's on
> the first four bytes of it.
Sure, but when I bind to a grid, I need to know a-priori how big the
biggest returned instance can be. Reading the entire data set twice to
learn the size of a constant seems rather conceptually odd to me.
---------------------------(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
