Noah Misch <noah@leadboat.com> writes:
> On Tue, May 24, 2011 at 12:12:55PM -0400, Tom Lane wrote:
>> This is a consequence of the changes I made to fix bug #5717,
>> particularly the issues around ANYARRAY matching discussed here:
>> http://archives.postgresql.org/pgsql-hackers/2010-10/msg01545.php
> We discussed this a few weeks ago:
> http://archives.postgresql.org/message-id/20110511093217.GB26552@tornado.gateway.2wire.net
> What's to recommend #1 over what I proposed then? Seems like a discard of
> functionality for little benefit.
I am unwilling to commit to making #2 work, especially not under time
constraints; and you apparently aren't either, since you haven't
produced the patch you alluded to at the end of that thread. Even if
you had, though, I'd have no confidence that all holes of the sort had
been closed. What you're proposing is to ratchet up the implementation
requirements for every PL and and every C function declared to accept
polymorphic types, and there are a lot of members of both classes that
we don't control.
> I hesitate to say this is so clearly right as to warrant that change. Even if
> it is right, though, this smells like 9.2 material.
Well, I'd been hoping to leave it for later too, but it seems like we
have to do something about the ANYARRAY case for 9.1. Making ANYARRAY's
response to domains significantly inconsistent with ANYELEMENT's
response doesn't seem like a good plan.
regards, tom lane
