"Dann Corbit" <DCorbit@connx.com> writes:
> In the case of a SELECT query that selects a fixed constant of any sort,
> it would be a definite improvement for PostgreSQL to give some sort of
> upper maximum.
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".
In my opinion, variable-length data is a fact of life and you should
endeavor to make your code deal with it gracefully. There are bits of
the SQL spec that assume fixed-width data specifications are useful,
but to be blunt that's all a holdover from 1960s 80-column-punch-card
thinking. It's no way to design a modern application.
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.
regards, tom lane
