createdb with alternate location
От | Peter Eisentraut |
---|---|
Тема | createdb with alternate location |
Дата | |
Msg-id | Pine.LNX.4.20.9912112237160.6044-100000@localhost.localdomain обсуждение исходный текст |
Ответы |
Re: [HACKERS] createdb with alternate location
Re: [HACKERS] createdb with alternate location |
Список | pgsql-hackers |
In my venturing into createdb/dropdb I came to that little artifact that allows you to create databases at alternate locations using environment variables as part of the path (CREATE DATABASE elsewhere WITH LOCATION = 'PGDATA2/foo'). The problem with this is that it doesn't work. It never could have, and God help you if you try to use it anyway. And it's not only one isolated problem. First off, the paths generated by the expansion and the ones generated by initlocation are different, so the directory will never be found unless you tweak it by hand. This can be fixed. Worse, however, is that the expanded path is stored in pg_database (at least in theory, since you never get there) and once you try to reference (e.g., remove) the database, the same expansion routine will see the now absolute path and refuses to allow it. What really gets me, though, is how this sort of scheme is supposed to create security in the first place. Perhaps I can create a path based on the environment variable HOME, or maybe SHELL? Or how about this: you take an empty environment variable and specify VAR/usr/local/pgsql/lib as your path. Fun ensues! You can never completely control this stuff. ISTM, this just makes things worse and more complicated. How could we still keep this feature but select another method of specifying the list of allowed paths? The Unix file permissions should help, but that doesn't necessarily prevent anyone from frying your existing databases, if you exercise a little imagination when specifying the paths. How about a) something in some options file (lot of work), or b) some environment variable of the form PGSQL_ALTLOC=path:path:path? This is of course barring the potential fact that parts of the code which I don't completely understand or which I haven't read yet prevent this whole concept from working in other ways. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
В списке pgsql-hackers по дате отправления: