Re: pgsql: Add a security_barrier option for views.
| От | Alvaro Herrera |
|---|---|
| Тема | Re: pgsql: Add a security_barrier option for views. |
| Дата | |
| Msg-id | 1324594168-sup-2795@alvh.no-ip.org обсуждение исходный текст |
| Ответ на | Re: pgsql: Add a security_barrier option for views. (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-committers |
Excerpts from Tom Lane's message of jue dic 22 19:09:54 -0300 2011: > > Alvaro Herrera <alvherre@commandprompt.com> writes: > > Excerpts from Tom Lane's message of jue dic 22 18:39:18 -0300 2011: > >> Robert Haas <rhaas@postgresql.org> writes: > >>> Add a security_barrier option for views. > > >> Where's the catversion bump for having broken stored rules/views? > > > I'm starting to wonder if we should have a git hook of some sort to > > check for this ... > > Dunno, how would you automate that? > > My rule of thumb is that touching either src/include/catalog/* or > readfuncs.c probably means you need a catversion bump. It's the > "probably" that's a problem for automated enforcement. I don't > want unnecessary catversion bumps happening just because some tool > is preventing a commit. Yeah, maybe this belongs in a tool local to each developer. I run a script here "git-safe-push" (yes, from Magnus) that, currently, displays the commits I have for pushing, so that I can double check that I'm not pushing something improper. I guess I could integrate something that if there's a hunk touching src/include/catalog, it raises a warning and nothing more, so I can easily ignore it if it's wrong. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
В списке pgsql-committers по дате отправления: