Re: 9.2: Describing a security barrier view in psql
От | Dean Rasheed |
---|---|
Тема | Re: 9.2: Describing a security barrier view in psql |
Дата | |
Msg-id | CAEZATCWQQtOSJ6H1CdT5tc+jCncgW=C2k+E7oMwTZ0JmBfHgKg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: 9.2: Describing a security barrier view in psql (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 3 September 2012 14:48, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Dean Rasheed <dean.a.rasheed@gmail.com> writes: >> Unless I'm missing something, it is not possible in psql to tell >> whether a view has the security_barrier option. I think that this is >> something that ought to be possible from psql, otherwise the new >> feature is not visible. > >> This patch displays any reloptions for a view at the end, if \d+ is >> used, in the same way as for tables. > >> Sorry if this is too late for 9.2. I really only just noticed this, >> despite playing with security barrier views for a while. > > Seems to me we should include this into 9.2, since the security_barrier > feature exists there. It's not quite too late. Any objections? > > I'd be inclined to go about it a bit differently though: rather than > duplicating the code, in a way that's *still* wrong the next time we > enable reloptions for a new relkind, I think we should just pull the > reloptions-printing code block out of where it is and print reloptions > regardless of relkind, if verbose and there are some. This would have > the effect of switching the order of the tablespace and reloptions > footers when both are present, but that doesn't bother me any - the > existing order is only a historical artifact anyway AFAIK. > Yes that makes sense. I was just going for the minimal quick fix. Regards, Dean
В списке pgsql-hackers по дате отправления: