Re: security label support, revised

Robert,

First off, thanks alot for working on this.  My apologies for not having
time to help out.  A few minor comments:

* Robert Haas (robertmhaas@gmail.com) wrote:
> Most of the contents of the new documentation section on external
> security providers seemed irrelevant to me, which I guess I can only
> blame myself for since I was the one who asked for that section to be
> created, and I didn't specify what it should contain all that well.  I
> took a try at rewriting it to be more on-topic, but it didn't amount
> to much so I ended up just ripping that part out completely.

Do we have a place where we actually document hooks today..?  Seems like
we should and that'd be a good place to put the few necessary comments
regarding these.

> There are a few other problems.  First, there's no psql support of any
> kind.  Now, this is kind of a corner-case feature: so maybe we don't
> really need it.  And as I mentioned on another thread, there aren't a
> lot of good letters left for backslash-d commands.

One thought would be to add it to \dp or have a \dp+.

> So I'd be just as
> happy to add a system view along the lines I previously proposed for
> comments and call it good.

I think that regardless of psql and \d, we should have a sensible system
view for it.

> Second, there are no
> regression tests.  It's a bit tricky to think about how to crack that
> nut because this feature is somewhat unusual in that it can't be used
> without loading an appropriate loadable module.  I'm wondering if we
> can ship a "dummy_seclabel" contrib module that can be loaded during
> the regression test run and then run various tests using that, but I'm
> not quite sure what the best way to set that up is.  SECURITY LABEL is
> a core feature, so it would be nice to test it in the core regression
> tests...  but maybe that's too complicated to get working, and we
> should just test it from the contrib module.

The first set of regression tests could simply run the SECURITY LABEL
commands and then check the results in the catalog.  If some kind of
psql support is included, it could test that also.  That doesn't check
that the hooks are called at the right time and with the right data, so
I agree with the suggestion to have dummy contrib modules (or something)
to do that generically for all our hooks, but I don't think we've got
anything like that today..?  If we do, then we should model it off
whatever's there now.  Perhaps we can look at how to do it
comprehensively for all hooks..
Thanks,
    Stephen