On Thu, May 12, 2016 at 12:18 AM, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> wrote: > I think if scanning a foreign join, the user mapping is still valid at > execution, and that is ensured by RevalidateChachedQuery, IIUC.
Yes, we added special machinery for that, along the lines of what is also done for RLS. But I have to say I don't like this patch very much. The problem here is that we want to store an unsigned integer in a node tree, but makeInteger() takes a long, and there's no other similar node that accepts an OID instead. Your solution to that problem is not to store the data at all, which seems like letting the tail wag the dog. Maybe the performance difference in this case is minor and maybe it's not, but that isn't really the point. The point is that storing an OID is a pretty reasonable thing to want to do, and we should find a way to do it instead of working around the problem. My suggestion is that we switch from using a List to marshal the data to using an ExtensibleNode. An advantage of that is that we'd have some in-core test coverage for the ExtensibleNode stuff. In theory it ought to be simpler and less messy, too, but I guess we'll find out. Regardless of what approach we take, I disagree that this needs to be fixed in 9.6. The only people who are going to be hurt by this are people who are using postgres_fdw and reading node-tree dumps and have an OID counter that advances past 2 billion. And those people are going to be pretty rare, and they'll just have to live with it. It's more important to keep the code stable than to fix a minor issue like this. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
