Re: Foreign table permissions and cloning

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Shigeru Hanada <hanada(at)metrosystems(dot)co(dot)jp>, Thom Brown <thom(at)linux(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Foreign table permissions and cloning
Date: 2011-04-25 20:13:58
Message-ID: BANLkTimyLUN1o1GmxRxROSqWjsavMUEJ9Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Apr 25, 2011 at 7:02 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Yeah, the existing precedent (not only for GRANT but for some other
> things like ALTER TABLE) is that a command that says "TABLE" is allowed
> to apply to other relation types if it makes sense to apply it.  It's
> only when you name some other object type that we get picky about the
> relkind matching exactly.  This is probably more historical than
> anything else, but it's the precedent and we shouldn't make foreign
> tables be the only thing not following the precedent.

Actually I vaguely remember some earlier pass through this code to
make it more consistent. IIRC we previously had some commands that
could only be done through ALTER TABLE even for things like sequences
and views and other commands that had corresponding ALTER VIEW
commands. I'll try to see if I can dig up the messages on the topic.

--
greg

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Farina 2011-04-25 20:21:57 Re: fsync reliability
Previous Message Todd A. Cook 2011-04-25 20:10:33 Re: "stored procedures" - use cases?