On Thu, May 12, 2016 at 12:18 AM, Etsuro Fujita
<fujita.etsuro@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