On Wed, Oct 4, 2017 at 6:13 PM, Jeff Janes <jeff.janes@gmail.com> wrote: > OK. And if you want the first one, you can wrap it in a view currently, but > if it were changed I don't know what you would do if you want the 2nd one > (other than having every user create their own set of foreign tables). So I > guess the current situation is more flexible.
So where does that leave this patch?
Sorry, I thought we were just having a digression. I didn't think that part was about this patch specifically, but what more could be done later.
I don't think it makes this patch a bad idea, although I kind of lean towads the view that the patch should just be checking superuser_arg(), not superuser() || superuser_arg().
I don't see a reason to block a directly-logged-in superuser from using a mapping. I asked in the closed list whether the current (released) behavior was a security bug, and the answer was no. And I don't know why else to block superusers from doing something other than as a security bug. Also it would create a backwards compatibility hazard to revoke the ability now.
