Noah Misch <n...@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.gb26...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
