Re: Selecting a constant question: A summary

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