Re: Selecting a constant question: A summary

"Andrew Hammond" <andrew(dot)george(dot)hammond(at)gmail(dot)com> writes:
> - 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.

Well, I don't see any reason that we'd consider an implicit cast to
char(N) without context to drive us in that direction. The system is
currently biased to prefer casts to text. You could make a reasonable
case for forcing a cast to text if the constant's type is still
unresolved at the end of parsing, and indeed people have proposed that
off and on just so that clients would have one less type to think about.
In itself it doesn't do anything for Dann's problem though, because
unspecified width is unspecified width.

I've been thinking lately about trying harder to unify the text and
varchar types; I'm not sure about details yet, except that text should
be *exactly* the same thing as unconstrained-width varchar, rather than
almost the same except we claim it's a different type. The reason I'd
been thinking about this was mainly to get rid of the complexity and
runtime overhead that comes from having RelabelType nodes all over the
place when someone uses varchar instead of text. But if we did that,
we could also arrange that unknown literals coerce to varchar(N) with
N equal to their actual width, rather than coercing to text, and not
create any weird corner-case behaviors in the type system.

But at the end of the day this all would only solve Dann's problem for
the specific case of a SELECT with an undecorated literal constant in
its target list. He's still going to have to deal with unknown-width
columns in an enormous variety of cases, and so I completely fail to see
the point of changing the system's behavior for this one case.

regards, tom lane