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