While running down loose ends in my domains-over-composite patch, I wondered why parse_func.c's FuncNameAsType() excludes composite types as possible type names. I could set up the patch to treat composite domains the same way, or not, but it wasn't obvious what to do because the point of the exclusion wasn't clear.
Some excavation in our git history shows that the exclusion was added here: commit 990eb8552e69a492840d46b58ceb630a8a295e54 Author: Tom Lane <t...@sss.pgh.pa.us> Date: Wed Dec 12 03:28:49 2001 +0000 Don't accept names of complex types (ie, relation types) as being requests for implicit trivial coercions. Prevents sillinesses like this one: regression=# select x.int8_tbl.q1 from int8_tbl x; ERROR: fmgr_info: function 270997776: cache lookup failed I could not find any contemporaneous discussion in the list archives, so I'm guessing that I tripped over this corner case and did not think it was worth spending any great amount of effort on. But in hindsight the fix sure looks like a band-aid that's covering up a deeper problem. Whatever that problem was, it's gone now --- if I dike out the check then the parser correctly concludes that coercing int8_tbl to int8_tbl is a no-op. You need more parens nowadays, but either of these work: select (x.int8_tbl).q1 from int8_tbl x; select (int8_tbl(x)).q1 from int8_tbl x; There might still be an argument for rejecting the case on the grounds that it's confusing or likely to be user error, but I'm not sure. It seems weirdly asymmetric that we allow typename(x) to be a coercion request unless typename is a composite type. And that exception is not documented in any of the places that talk about this syntax, e.g. section 4.2.9, section 10.3 rule 3, or the CREATE CAST man page. So I'm inclined to remove the exception for composite types, effectively reverting 990eb8552. Alternatively, if we keep it, it needs to be documented as to the reasoning for having it. Thoughts? regards, tom lane -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers