Skip site navigation (1) Skip section navigation (2)

Typmod associated with multi-row VALUES constructs

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Typmod associated with multi-row VALUES constructs
Date: 2016-12-05 20:08:58
Message-ID: 27429.1480968538@sss.pgh.pa.us (view raw, whole thread or download thread mbox)
Thread:
Lists: pgsql-hackers
I looked into the issue reported in bug #14448,
https://www.postgresql.org/message-id/20161205143037.4377.60754%40wrigleys.postgresql.org

The core of it seems to be that expandRTE() will report the type and
typmod of a column of a VALUES construct as being exprType() and
exprTypmod() of the corresponding expression in the first row of
the VALUES.  It's okay to handle data type that way, because we've
coerced all the expressions for the column to the same type; but
we have *not* coerced them to the same typmod.  So some of the values
from later rows may fail to meet the claimed typmod.  This is not good.

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.

#1 is what we do for some comparable cases such as UNION and CASE.
However, it's potentially quite expensive for large VALUES constructs.
#2 would be a lot cheaper, and given that this is the first complaint
we've gotten in all the years we've had multi-row-VALUES support, it's
not clear that deriving a precise typmod is really all that useful
for VALUES.

I have no strong preference between these two, but I think whatever
we do needs to be back-patched.  The behavior described in the bug
report is definitely broken.

Thoughts?

			regards, tom lane


Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2016-12-05 20:12:30
Subject: Re: Creating a DSA area to provide work space for parallel execution
Previous:From: Andreas SeltenreichDate: 2016-12-05 20:07:58
Subject: [sqlsmith] Crash in gather_readnext

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group