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