Re: Typmod associated with multi-row VALUES constructs

On Mon, Dec 5, 2016 at 2:22 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> > On Mon, Dec 5, 2016 at 1:08 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> In order to fix this, we first have to decide what the semantics ought
> >> to be. I think there are two plausible definitions:
> >> 1. If all the expressions in the VALUES column share the same typmod,
> >> use that typmod, else use -1.
> >> 2. Use -1 whenever there is more than one VALUES row.
>
> > ​Can we be precise enough to perform #2 if the top-level (or immediate
> > parent) command is an INSERT - the existing table is going to enforce its
> > own typemod anyway, otherwise go with #1?
>
> I dunno if that's "precise" or just "randomly inconsistent" ;-)
>

:)

How does "targeted optimization" sound?

> > ​Lacking that possibility I'd say that documenting that our treatment of
> > typemod in VALUES is similar to our treatment of typemod in function
> > arguments would be acceptable. This suggests a #3 - simply use "-1"
> > regardless of the number of rows in the VALUES expression.
>
> I'm a bit concerned about whether that would introduce overhead that we
> avoid today, in particular for something like
>
> insert into foo (varchar20col) values ('bar'::varchar(20));
>
> I think if we throw away the knowledge that the VALUES row produces the
> right typmod already, we'd end up adding an unnecessary runtime coercion
> step.
>

​Unnecessary maybe, but wouldn't it be immaterial given we are only able to
be efficient when inserting exactly one row.

There is also a #4 here to consider - if the first (or any) row is not type
unknown, and the remaining rows are all unknown, use the type and typemod
of the known row AND attempt coerce all of the unknowns to that same type.
I'd suggest this is probably the most user-friendly option (do as I mean,
not as I say). The OP query would then fail since the second literal is
too long to fit in a varchar(20) - I would not want the value truncated so
an actual cast wouldn't work.

David J.

David J.