Tom,
> What's the point? You keep reminding us that your code is middleware
> that can't assume anything much about the queries you're dealing with.
> Therefore, I see no real value in fixing up one corner case. Your
> argument about space allocation falls to the ground unless we can
> provide a guaranteed, and usefully tight, upper bound on the column
> width in *every* situation. If we cannot (which we can't), you're still
> going to need those client-side "kluges".
Hmmm? I thought that Dann was just talking about constants, and not column
results. Am I confused?
> BTW, the reason I'm resistant to even thinking about this is that
> Postgres is designed as an extensible system. Trying to do what you
> want is not a matter of fixing literal constants and concatenation
> and one or two other places --- it's a matter of imposing a new and
> potentially hard-to-meet requirement on every datatype under the sun,
> including a lot of user-written code that we don't control and would
> break by adding such a requirement. So it's not even likely that we'd
> think very hard about making this work, let alone actually do it.
I'd think it would be possible to do this in an abstract way ... having a
"DisplayLength()" call for each data type and value. That would require
casting the constant, though, or computing all uncast constants as text.
--
Josh Berkus
PostgreSQL @ Sun
San Francisco