Re: Selecting a constant question
От | Dann Corbit |
---|---|
Тема | Re: Selecting a constant question |
Дата | |
Msg-id | D425483C2C5C9F49B5B7A41F8944154701000718@postal.corporate.connx.com обсуждение исходный текст |
Ответ на | Re: Selecting a constant question (Martijn van Oosterhout <kleptog@svana.org>) |
Ответы |
Re: Selecting a constant question
|
Список | pgsql-hackers |
> -----Original Message----- > From: Martijn van Oosterhout [mailto:kleptog@svana.org] > Sent: Monday, June 11, 2007 3:29 PM > To: Dann Corbit > Cc: Alvaro Herrera; Gregory Stark; pgsql-hackers@postgresql.org; Larry > McGhaw > Subject: Re: [HACKERS] Selecting a constant question > > On Mon, Jun 11, 2007 at 03:18:33PM -0700, Dann Corbit wrote: > > 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. > > To be honest, the concept that a widget requires a constant that can't > be changed later is also a bit odd. Not when the data itself is a constant that cannot be changed. > There are many times you won't know > beforehand how big the data is, surely the framework should be smart > enough to handle these cases? If it were impossible to know the size of a string constant supplied in the query, then I think I would agree with you here. However, it seems to me that the maximum possible size of such a known, constant-width string is not hard to determine. > Start the width at 100, if it turns out to be too small, make it > bigger... If that were a good idea, then why report data sizes at all? Just let it always be a surprise when it comes streaming down the pipe. Honestly, I cannot fathom this answer.
В списке pgsql-hackers по дате отправления: