Re: Selecting a constant question: A summary - Mailing list pgsql-hackers

On 6/12/07, Josh Berkus <josh@agliodbs.com> wrote:
> 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.

The simplest formulation of this problem appears to be that constant
strings that are uncast are treated as type unknown. The connx guys
seem to think that they should be implicitly cast to char(n) where n
is the length of the string. Is that a reasonable description, or are
you guys looking for something more general?

If you're just talking about the strings, then here are the thoughts
I've gleaned from the preceding thread.

- This makes possible some performance tweaks for drivers
- It achieves spec compliance (albeit for a stupid part of the spec)
- Implicit casting of unknown to char(n) or anything else seems rather
sketchy to me, but I can't see any specific objection, except that...
- I don't know when the right time to do the cast is. And doing it too
early seems obviously wrong.
- This only helps in corner case of string constants that are 1. not already cast and 2. not manipulated in any way
And that seems like a very small corner case with little or no
practical use. I guess if you have some code that turns query output
into some flavor of pretty-print, it'd make sense to have a constant
column as output of a CASE statement or something.
- The corner case must already be correctly handled by the general
case for arbitrary sized text, or alternatively phrased: there is no
way to conform to the standard while supporting arbitrary sized text.
Unless you're willing to pay the cost of scanning twice, or
maintaining "biggest entry" data for each variable length column.
- I don't know how much effort it would require to implement this, nor
how much complexity it would add to the code base. Clearly both of
these would be non-zero values.

Given the above, I agree with Tom: this seems like corner case where
the returns are marginal at best, compared to the cost to implement
and maintain.

Is there something I'm getting wrong in this summary?

Andrew