Robert Haas <robertmh...@gmail.com> wrote: >> 2. The notation t(x) will be taken to mean x::t if there's no >> function t() taking x's type, but there is a cast from x's type >> to t. >> I think if I had to pick a proposal, I'd say we should disable #2 >> for the specific case of casting a composite type to something >> else. > Well, then let's do that. It's not the exact fix I'd pick, but > it's clearly better than nothing, so I'm willing to sign on to it > as a compromise position. It seems a bad idea to have so many different syntaxes for identical CAST semantics, but there they are, and it's bad to break things. One of the reasons #2 seems like the place to fix it is that it's pretty flaky anyway -- "it will be taken to mean x unless there no y but there is a z" is pretty fragile to start with. Adding one more condition to the places it kicks in doesn't seem as good to me as dropping it entirely, but then I don't have any code which depends on type(value) as a cast syntax -- those who do will likely feel differently. So, I'd rather scrap #2 entirely; but if that really would break much working code, +1 for ignoring it when it would cast a composite to something else. -Kevin
-- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
