(2010/09/24 11:53), Robert Haas wrote: > 2010/9/23 KaiGai Kohei<kai...@ak.jp.nec.com>: >>> 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. >>> >> One headache thing when I tried to describe the new documentation section >> was what we should describe here, because whole of the chapters in Server >> Administration are on the standpoint of users, not developers. >> >> Under the previous discussion, I suggested to move the most of descriptions >> about external security providers into chapters in Internals, except for >> a mention about a fact we have external security provider at the tail of >> Database Roles and Privileges. How about the idea? >> Perhaps, the chapters in Internals are appropriate place to introduce >> specification of security hooks. > > Perhaps. I know that in the past we have not documented hook > functions, and I'm thinking that there may be people (in particular, > possibly Tom) who have strong feelings about keeping it that way. > Even if that's not the case, once we do start documenting the hooks, > we will presumably need to document all of them, and that may be more > of a project than I really want to get into right now, especially if I > will have to do much of the work myself. I'd be perfectly ecstatic if > a committable patch spontaneously materialized, but... > If so, maybe, we should keep the scale of documentation to a minimum, then, rest of the detailed specifications of hooks are kept as source code comments. Because authors of ESP obviously reference source code, the comments will provide them enough information.
>>> Also, the pg_dump support for security labels should >>> really reuse the existing design for comments, rather than inventing a >>> new and less efficient method, unless there is some really compelling >>> reason why the method used for comments won't work. Please send a >>> reworked patch for just this directory (src/bin/pg_dump). >>> >> I intended to follow on the existing design for comments. >> Could you suggest me how should it be fixed up the design? > > dumpComment calls findComments calls collectComments, which dumps all > the comments in one query (not one query per object). > >> Because of the --no-security-label option, we need to dump security >> labels in a separated section from comments. So, we cannot pack them >> into "COMMENT" sections. > > I'm not proposing that - I just want to avoid sending so many database > queries, if that's possible. > Ahh, Thanks. It makes me clear. I'll revise dumpSecLabel to call findSecLabels and collectSecLabels on the first call. >>> 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. So I'd be just as >>> happy to add a system view along the lines I previously proposed for >>> comments and call it good. Alternatively, or in addition, we could >>> add a \d command after all. The best way forward is debatable, but we >>> certainly need *something*, because interpreting the pg_seclabel >>> catalog by hand is not for the faint of heart. >> >> Do you suggest the new system views should be defined for each supported >> object classes, such as pg_largeobject_seclabel? It seems to me a bit >> inflation of number of system views. >> My preference is psql's \d commands at first. > > Please see http://archives.postgresql.org/pgsql-hackers/2010-09/msg01080.php > OK, I'll emulate this approach at first. Thanks, -- KaiGai Kohei <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
