| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Postgres-Bugs <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: Failure to coerce unknown type to specific type |
| Date: | 2015-05-03 19:33:51 |
| Message-ID: | 23845.1430681631@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
Kevin Grittner <kgrittn(at)ymail(dot)com> writes:
> Section 9.3, which the definition of COALESCE references as the
> way to resolve type conflicts *starts* with this:
> | Let IDTS be the set of data types specified in an application of
> | this Subclause. Let DTS be the set of data types in IDTS
> | excluding any data types that are undefined. If the cardinality
> | of DTS is 0 (zero), then the result data type is undefined and no
> | further Rules of this Subclause are evaluated.
> That's pretty unambiguous that a COALESCE(NULL, NULL) clause should
> yield a NULL with the data type undefined.
This is irrelevant, because such a construct fails the syntax rules
and thus we never get to the question of what type should be inferred,
at least not without going outside the spec. See my other reply.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Grittner | 2015-05-03 20:07:13 | Re: Failure to coerce unknown type to specific type |
| Previous Message | Kevin Grittner | 2015-05-03 19:29:55 | Re: Failure to coerce unknown type to specific type |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2015-05-03 19:57:43 | Re: Manipulating complex types as non-contiguous structures in-memory |
| Previous Message | Kevin Grittner | 2015-05-03 19:29:55 | Re: Failure to coerce unknown type to specific type |