Thread: avoid create a tablespace in pg_tblspc
Hi, bug report http://archives.postgresql.org/pgsql-bugs/2008-10/msg00037.php seems like a reasonably request to me... and one that is simple to fulfill, just create a PG_VERSION in the pg_tblspc dir at initdb. if no one objects, here is a one linear patch for that -- regards, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157
Attachment
"Jaime Casanova" <jcasanov@systemguards.com.ec> writes: > bug report http://archives.postgresql.org/pgsql-bugs/2008-10/msg00037.php > seems like a reasonably request to me... and one that is simple to > fulfill, just create a PG_VERSION in the pg_tblspc dir at initdb. I don't think it's a reasonable request. If we take this seriously, we'd have to buy into making sure that no subdirectory of $PGDATA is ever empty. Which is silly. And what of empty directories elsewhere? There are any number of ways to shoot yourself in the foot with a bad choice of tablespace location --- I don't find this one more dangerous than any other. regards, tom lane
On Thu, Oct 9, 2008 at 6:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Jaime Casanova" <jcasanov@systemguards.com.ec> writes: >> bug report http://archives.postgresql.org/pgsql-bugs/2008-10/msg00037.php >> seems like a reasonably request to me... and one that is simple to >> fulfill, just create a PG_VERSION in the pg_tblspc dir at initdb. > > I don't think it's a reasonable request. If we take this seriously, > we'd have to buy into making sure that no subdirectory of $PGDATA is > ever empty. Which is silly. And what of empty directories elsewhere? > There are any number of ways to shoot yourself in the foot with a bad > choice of tablespace location --- I don't find this one more dangerous > than any other. > well, this one can at least create a tablespace that never can be dropped -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157