| From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
|---|---|
| To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Typmod associated with multi-row VALUES constructs |
| Date: | 2016-12-06 01:46:17 |
| Message-ID: | CAMsr+YHk6Zmisx69nfq4bu0Cx4gOVYJyRQ0FFdH9tGU1Tn1tEg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 6 December 2016 at 04:52, David G. Johnston
<david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> 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?
We already routinely throw away typmod information in other places,
and can only truly rely on it when working directly with data in
tables. So it sounds sensible to me.
I see semi-regular complaints about this from JDBC users, who want to
be able to know things like "number of digits in this numeric" and
"can this column be null" even through various projections and
transformations of results. But I don't think your suggested change
will make the existing situation any worse.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David G. Johnston | 2016-12-06 01:59:42 | Re: Typmod associated with multi-row VALUES constructs |
| Previous Message | Tom Lane | 2016-12-06 01:37:06 | Re: Select works only when connected from login postgres |