On Tue, Jun 30, 2009 at 4:39 AM, Josh Berkus<j...@agliodbs.com> wrote: > > >> Well I don't understand how you get them wrong if you're just pasting >> them from a file. I mean, sure you can pick the wrong template but >> nothing can help you there. You could just as easily pick the wrong >> template if it's a database feature instead of a text file. > > I really have to wonder if you've ever managed a production database > project. > > As someone who has managed quite a few, my idea of the feature is designed > to make my life (and my clients') easier. It's *vastly* easier to tell > developers "don't touch the permissions, it will take care of itself" and > set it in a central location than to expect them to remember to apply a set > of permissions each time, or follow them around playing catch-up on the > objects they add and modify.
But that's not what we're talking about and there's no way they can just "take care of themselves". The database isn't a mind-reader and can't know whether this new table is supposed to have the "public web data" permission template or the "sensitive data" permission template. You can put it in the wrong schema and get the wrong default permission just as easily as you can choose the wrong text template to paste into your database creation script. I'm not saying it's a bad idea to have some sort of short cut for the default permissions. Actually it sounds like it would lend itself to the good code practice of being self-documenting which makes it easier to see that which template's being used which is sounds like quite a good thing. But you do still have to think carefully about that choice. Perhaps tieing it to the schema is wrong and we should actually require the user to specify the template they want explicitly which would be even better for that. So it would be something like "WITH GRANTS LIKE sensitive_table". -- greg http://mit.edu/~gsstark/resume.pdf -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers