Thomas Lockhart writes:
 > So pg_location would hold the full path (absolute or logical) to every
 > file resource in every database? Or would it hold only a list of
 > allowed paths? Or only a list of resources for each database (~1 row
 > per database) and then table-specific info would be stored somewhere
 > local to the database itself?
 > 
Is a list of allowed paths really necessary?  If initlocation has already
been run so a directory tree with the proper structure and permissions
exists there'd be no new security hole (ie, I couldn't ask the backend to
create a database on any arbitrary partition; only one that's already been
prepared by the administrator).

I'd like to see a list of resources per database, with any table-specific
info stored locally.

 >   ALTER TABLE SET LOCATION=...
 > and/or
 >   ALTER DATABASE SET LOCATION=...
 > should help administration and scalability.
 > 
Definitely.  Of course, I'd want to make sure any new LOCATION had been
prepared by the administrator.

 > But hard to do? If pg_location has 5000 entries, and you've scattered
 > tables all over the place (perhaps a bad decision, but we *should*
 > have the flexibility to do that) then it might be very error prone
 > when working with absolute paths imho.
 > 
I'd think that a pg_location entry wouldn't be necessary for the majority
of tables -- the default location would be just like it is now, under the
database directory.  Creating a database directory in one place and
scattering the tables all over creation would definitely be a Bad Decision,
IMHO, but it would be doable.

 > Putting absolute path names as pointers to tables or data areas. I'm
 > getting the sense I'm in a minority (in a group of 3? ;) in this
 > discussion, but imho having some decoupling between logical paths in
 > the database and actual paths outside is A Good Thing. Always has been
 > a mark of good design in my experience.
 > 
How about requiring an absolute path for the data(base) area, and
allowing relative paths for the tables?  Actually, if you want
ALTER DATABASE SET LOCATION=...
to move tables, you'd either have to require relative paths for the
tables or ignore tables that have absolute paths, right?

Hmm.  And all I originally wanted was an easier way to create a database in
an alternate location :-).

                        - Rich

-- 
Richard Kuhns                   [EMAIL PROTECTED]
PO Box 6249                     Tel: (765)477-6000 \
100 Sawmill Road                                    x319
Lafayette, IN  47903                 (800)489-4891 /

Reply via email to