On 09/02/2015 10:10 PM, dinesh kumar wrote: > On Tue, Sep 1, 2015 at 10:58 PM, Stefan Kaltenbrunner > <ste...@kaltenbrunner.cc <mailto:ste...@kaltenbrunner.cc>> wrote: > > On 07/25/2015 03:38 AM, dinesh kumar wrote: > > > > > > On Fri, Jul 24, 2015 at 10:22 AM, Robert Haas <robertmh...@gmail.com > <mailto:robertmh...@gmail.com> > > <mailto:robertmh...@gmail.com <mailto:robertmh...@gmail.com>>> wrote: > > > > On Thu, Jul 23, 2015 at 8:15 PM, dinesh kumar > > <dineshkuma...@gmail.com <mailto:dineshkuma...@gmail.com> > <mailto:dineshkuma...@gmail.com <mailto:dineshkuma...@gmail.com>>> > wrote: > > > On Thu, Jul 23, 2015 at 9:21 AM, Robert Haas > > <robertmh...@gmail.com <mailto:robertmh...@gmail.com> > <mailto:robertmh...@gmail.com <mailto:robertmh...@gmail.com>>> wrote: > > >> > > >> On Thu, Jul 23, 2015 at 12:19 PM, dinesh kumar > > <dineshkuma...@gmail.com <mailto:dineshkuma...@gmail.com> > <mailto:dineshkuma...@gmail.com <mailto:dineshkuma...@gmail.com>>> > > >> wrote: > > >> > Sorry for my unclear description about the proposal. > > >> > > > >> > "WITH PERMISSIVE" is equal to our existing behavior. That > is, chmod=644 > > >> > on > > >> > the created files. > > >> > > > >> > If User don't specify "PERMISSIVE" as an option, then the > chmod=600 on > > >> > created files. In this way, we can restrict the other > users from reading > > >> > these files. > > >> > > >> There might be some benefit in allowing the user to choose the > > >> permissions, but (1) I doubt we want to change the default > behavior > > >> and (2) providing only two options doesn't seem flexible > enough. > > >> > > > > > > Thanks for your inputs Robert. > > > > > > 1) IMO, we will keep the exiting behavior as it is. > > > > > > 2) As the actual proposal talks about the permissions of > group/others. So, > > > we can add few options as below to the WITH clause > > > > > > COPY > > > .. > > > .. > > > WITH > > > [ > > > NO > > > (READ,WRITE) > > > PERMISSION TO > > > (GROUP,OTHERS) > > > ] > > > > If we're going to do anything here, it should use COPY's > > extensible-options syntax, I think. > > > > > > Thanks Robert. Let me send a patch for this. > > > how are you going to handle windows or unix ACLs here? > Its permission model is quite different and more powerful than (non-acl > based) unix in general, handling this in a flexible way might soon get > very complicated and complex for limited gain... > > > Hi Stefan, > > I had the same questions too. But, I believe, our initdb works in these > cases, after creating the data cluster. Isn't ?
maybe - but having a fixed "default" is very different from baking a classic unix permission concept of user/group/world^others into actual DDL or into a COPY option. The proposed syntax might make some sense to a admin used to a unix style system but it is likely utterly incomprehensible to somebody who is used to (windows style) ACLs. I dont have a good answer on what to do else atm but I dont think we should embedded traditional/historical unix permission models in our grammer unless really really needed... Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers