[HACKERS] Re: Question about databases in alternate locations...

From: "Richard J(dot) Kuhns" <rjk(at)grauel(dot)com>
To: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-general(at)postgresql(dot)org, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: [HACKERS] Re: Question about databases in alternate locations...
Date: 2000-05-19 16:25:35
Message-ID: 14629.27391.756251.94479@sawmill.grauel.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers pgsql-sql

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 rjk(at)grauel(dot)com
PO Box 6249 Tel: (765)477-6000 \
100 Sawmill Road x319
Lafayette, IN 47903 (800)489-4891 /

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2000-05-19 16:39:17 Re: Performance (was: The New Slashdot Setup (includes MySql server))
Previous Message Tom Lane 2000-05-19 16:19:24 Re: Performance (was: The New Slashdot Setup (includes MySql server))

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-05-19 16:39:17 Re: Performance (was: The New Slashdot Setup (includes MySql server))
Previous Message Tom Lane 2000-05-19 16:19:24 Re: Performance (was: The New Slashdot Setup (includes MySql server))

Browse pgsql-sql by date

  From Date Subject
Next Message Peter Eisentraut 2000-05-19 17:39:14 Re: Foreign keys breaks tables permissions
Previous Message Tom Lane 2000-05-19 16:06:16 Re: SQL command speed