Re: Directory/File Access Permissions for COPY and Generic File Access Functions
От | Robert Haas |
---|---|
Тема | Re: Directory/File Access Permissions for COPY and Generic File Access Functions |
Дата | |
Msg-id | CA+Tgmobn7hyUKxgGjBVMZthYG2MdvWhMBaK9Zs0Z9c=SDMPW3g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Directory/File Access Permissions for COPY and Generic File Access Functions (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: Directory/File Access Permissions for COPY and Generic
File Access Functions
|
Список | pgsql-hackers |
On Tue, Oct 28, 2014 at 9:24 AM, Stephen Frost <sfrost@snowman.net> wrote: > That said, it sounds like the primary concern has been if we want this > feature at all and there hasn't been much discussion of the design > itself. Comments about the technical design would be great. I > appreciate your thoughts about using a PGC_SUSER GUC, but I don't feel > like it really works as it's all-or-nothing and doesn't provide > read-vs-write, unless we extend it out to be multiple GUCs and then > there is still the question about per-role access.. It sounds to me like you've basically settled on the way that you want to implement it - without prior discussion on the mailing list - and you're not trying very hard to make any of the alternatives work. It's not the community's job to come up with a design that satisfies you; it's your job to come up with as design that satisfies the community. That doesn't *necessarily* mean that you have to change the design that you've come up with; convincing other people that your design is the best one is also an option. But I don't see that you're making any real attempt to do that. Your previous comment on the idea of a PGC_SUSET GUC was "Hrm, perhaps this would work though.." and then, with zero further on-list discussion, you've arrived at "I don't feel like it really works as it's all-or-nothing and doesn't provide read-vs-write". Those are precisely the kinds of issues that you should be discussing here in detail, not cogitating on in isolation and then expecting this group of people to accept that your original design is really for the best after all. I also find your technical arguments - to the extent that you've bothered to articulate them at all - to be without merit. The "question about per-role access" is easily dealt with, so let's start there: if you make it a GUC, ALTER USER .. SET can be used to set different values for different users. No problem. Your other criticism that it is "all-vs-nothing" seems to me to be totally incomprehensible, since as far as I can see a GUC with a list of pathnames is exactly the same functionality that you're proposing to implement via a much more baroque syntax. It is no more or less all-or-nothing than that. Finally, you mention "read-vs-write" access. You haven't even attempted to argue that we need to make that distinction - in fact, you don't seem to have convinced a significantly majority of the people that we need this feature at all - but if we do, the fact that it might require two GUCs instead of one is not a fatal objection to that design. (I'd be prepared to concede that if there are half a dozen different privileges on directories that we might want to grant, then wedging it into a GUC might be a stretch.) -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: