On Tue, Jun 12, 2007 at 12:47:55PM +0200, Zeugswetter Andreas ADI SD wrote:
> I think this focuses too much on those cases where it is not possible.
> When it is not feasible like with a text column, clients deal with it
> already (obviously some better than others).
> It is for those cases where it would be feasible, like constants (or
> concateneted columns), where the max length if properly returned could
> be used to improve performance.
For constants there is a basic problem that Postgres, if at all
possible, doesn't even analyse the string at all. If it's not part of a
join or sort, then in every likelyhood it's passed through the entire
execution untouched and comes out the other end as type unknown. The
length indicator of -2 indicates a null-terminated string, postgres
never even bothered calculating the length of it.
For the situation of concatinating varchar columns, it's a fairly
special case. The typmod, in the *special case* of varchar is the
maximum length, but for other types it means something else.
Additionally, the planner doesn't know that || is concatination, a
consequence of the user-defined operators. So to make this work you
need to change the planner so that:
1. It special cases varchar to know what the typmod means
2. It special cases the || operator to add the typmods together.
3. Has to take special care not to break user-defined operators
All a pile of hacks and special cases to handle something that, to be
honest, the vast majority of people never notice.
So no, no patch is going to be accepted to handle this special case,
because it's far too hacky for a corner case. On the other hand, if you
can piggyback it into something like the "user-defined typmod" stuff,
it may have a better chance, though I really think the first problem is
basically "won't fix" from an optimisation point of view.
Hope this clarifies things a bit,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.