Now you have schema bla, table bla.boo, index bla.boo_pkey and sequence
bla.boo_id_seq all in tablespace foo. ISTM that tablespace foo cannot be
removed without hand-fixing pg_catalog and hand-moving files or links in
the database directory.
Hmmm, I wonder why the tablespace is set to the foo tabl
Fabien COELHO wrote:
>
> Dear Tom,
>
> > > psql> CREATE TABLE bla.boo(id SERIAL PRIMARY KEY);
> >
> > > Now you have schema bla, table bla.boo, index bla.boo_pkey and sequence
> > > bla.boo_id_seq all in tablespace foo.
> >
> > Hmm, that's a bug.
>
> If you consider that a bug, then you can al
Dear Tom,
> > psql> CREATE TABLE bla.boo(id SERIAL PRIMARY KEY);
>
> > Now you have schema bla, table bla.boo, index bla.boo_pkey and sequence
> > bla.boo_id_seq all in tablespace foo.
>
> Hmm, that's a bug.
If you consider that a bug, then you can also add: "CREATE SEQUENCE bla.sg;"
> The
Fabien COELHO <[EMAIL PROTECTED]> writes:
>> The sequences are in the same tablespace as the system catalogs of the
>> database they are in, so this objection is moot.
> three (unusual?) commands to reach the "moot" state:
> psql> CREATE TABLESPACE foo LOCATION '/tmp/postgres';
> psql
Dear Bruce,
Just my 0.02 euro cents:
On Sat, 28 Aug 2004, Bruce Momjian wrote:
> This is going to have to wait for 8.1. If it was so important, someone
> would have asked for it long before we went beta.
I'm not sure it works that way. Not that simply anyway.
Those having a say BEFORE beta ar
Christopher Kings-Lynne wrote:
> >>This is an extension of tablespaces, and is not required to fix a bug ...
> >>therefore, it is a feature, and not eligible for inclusion at this point
> >>in the development cycle ...
> >
> >
> > I am inclined to agree. ALTER INDEX is an operation that will h
Philip Warner <[EMAIL PROTECTED]> writes:
> On the question of schemas, how would you expect:
> SET magic_tablespace_variable = some_ts;
> CREATE SCHEMA foo;
> to behave? Would foo have a default tablespace of some_ts?
Yeah, I would think so. I sure don't see a value in inventi
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Marc G. Fournier wrote:
>>> We avoided this with oids but it seems we have added another. I don't
>>> see a good way of avoiding this like we had with oids.
>>
>> Isn't that what hte proposed (or implemented?) "SET DEFAULT_TABLESPACE"
>> was for?
> No
Marc G. Fournier wrote:
> On Mon, 23 Aug 2004, Bruce Momjian wrote:
>
> > Philip Warner wrote:
> >> At 03:15 PM 23/08/2004, Tom Lane wrote:
> >>
> >>> I thought the idea was for pg_dump to emit something like
> >>>
> >>> SET magic_tablespace_variable = some_ts;
> >>> CREATE TABLE f
On Mon, 23 Aug 2004, Bruce Momjian wrote:
Philip Warner wrote:
At 03:15 PM 23/08/2004, Tom Lane wrote:
I thought the idea was for pg_dump to emit something like
SET magic_tablespace_variable = some_ts;
CREATE TABLE foo (columns...);
rather than
CREATE TABLE foo (columns...)
Tom Lane wrote:
> Philip Warner <[EMAIL PROTECTED]> writes:
> > So, if you do make the changes, will the schema definition be affected by
> > those changes, or do you expect the tablespace to be embedded in the CREATE
> > SCHEMA command?
>
> I thought the idea was for pg_dump to emit something l
Tom Lane wrote:
> Philip Warner <[EMAIL PROTECTED]> writes:
> > On the question of schemas, how would you expect:
> > SET magic_tablespace_variable = some_ts;
> > CREATE SCHEMA foo;
> > to behave? Would foo have a default tablespace of some_ts?
>
> Yeah, I would think so. I sur
Philip Warner wrote:
> At 03:15 PM 23/08/2004, Tom Lane wrote:
>
> >I thought the idea was for pg_dump to emit something like
> >
> > SET magic_tablespace_variable = some_ts;
> > CREATE TABLE foo (columns...);
> >
> >rather than
> >
> > CREATE TABLE foo (columns...) TABLESP
At 03:15 PM 23/08/2004, Tom Lane wrote:
I thought the idea was for pg_dump to emit something like
SET magic_tablespace_variable = some_ts;
CREATE TABLE foo (columns...);
rather than
CREATE TABLE foo (columns...) TABLESPACE some_ts;
the point being...
Yep.
I am quite unsure
Philip Warner <[EMAIL PROTECTED]> writes:
> So, if you do make the changes, will the schema definition be affected by
> those changes, or do you expect the tablespace to be embedded in the CREATE
> SCHEMA command?
I thought the idea was for pg_dump to emit something like
SET magic_table
At 02:28 PM 23/08/2004, Tom Lane wrote:
There's been some talk of that, but AFAICS it's not related to an ALTER
SCHEMA SET [DEFAULT] TABLESPACE command.
So, if you do make the changes, will the schema definition be affected by
those changes, or do you expect the tablespace to be embedded in the CR
Philip Warner <[EMAIL PROTECTED]> writes:
> At 01:48 PM 23/08/2004, Marc G. Fournier wrote:
>> Won't the dump/restore "store" a "CREATE SCHEMA" onto the new
>> tablespace? Why would a dump/restore issue an ALTER SCHEMA part way through?
> We've had the same problem with CREATE TABLE statements.
At 01:48 PM 23/08/2004, Marc G. Fournier wrote:
Won't the dump/restore "store" a "CREATE SCHEMA" onto the new
tablespace? Why would a dump/restore issue an ALTER SCHEMA part way through?
My *belief* is that if the tablespace does not exist, then the restore
(which creates the schema and refers t
On Mon, 23 Aug 2004, Philip Warner wrote:
At 01:04 PM 23/08/2004, Marc G. Fournier wrote:
not having ALTER SCHEMA to move tablespaces is not a bug
But it does make pg_dump/restore more inclined to fail, so increases the
incidence of another bug, which can not be fixed without a global SET
DEFAULT
At 01:04 PM 23/08/2004, Marc G. Fournier wrote:
not having ALTER SCHEMA to move tablespaces is not a bug
But it does make pg_dump/restore more inclined to fail, so increases the
incidence of another bug, which can not be fixed without a global SET
DEFAULT TABLESPACE or an ALTER SCHEMA.
On Mon, 23 Aug 2004, Christopher Kings-Lynne wrote:
What the hey? For how long is that going to be our excuse for sucking?
No wonder everyone thinks we're newbie unfriendly and hard to use...
We are in a beta freeze ... not having ALTER SCHEMA to move tablespaces is
not a bug, and is not appropr
On Sunday 22 August 2004 21:34, Marc G. Fournier wrote:
> On Mon, 23 Aug 2004, Christopher Kings-Lynne wrote:
> >>> This is an extension of tablespaces, and is not required to fix a bug
> >>> ... therefore, it is a feature, and not eligible for inclusion at this
> >>> point in the development cycle
What the hey? For how long is that going to be our excuse for
sucking? No wonder everyone thinks we're newbie unfriendly and hard
to use...
We are in a beta freeze ... not having ALTER SCHEMA to move tablespaces
is not a bug, and is not appropriate for adding during a beta freeze ...
once 8.0
On Mon, 23 Aug 2004, Christopher Kings-Lynne wrote:
It will be 5 minutes before someone who has created a schema in 8.0 and
then will want to make it have a different default - there's no way they
can do it...
If they just created the schema, then a dump/reload would fix it ...
What the hey? For
It will be 5 minutes before someone who has created a schema in 8.0
and then will want to make it have a different default - there's no
way they can do it...
If they just created the schema, then a dump/reload would fix it ...
What the hey? For how long is that going to be our excuse for sucking
On Mon, 23 Aug 2004, Christopher Kings-Lynne wrote:
This is an extension of tablespaces, and is not required to fix a bug ...
therefore, it is a feature, and not eligible for inclusion at this point
in the development cycle ...
I am inclined to agree. ALTER INDEX is an operation that will happe
This is an extension of tablespaces, and is not required to fix a bug ...
therefore, it is a feature, and not eligible for inclusion at this point
in the development cycle ...
I am inclined to agree. ALTER INDEX is an operation that will happen
quite often, but I don't think ALTER SCHEMA will b
I'd like it applied, but change it to 'SET DEFAULT TABLESPACE' perhaps...?
Chris
Bruce Momjian wrote:
Would people like this applied to 8.0? It addresses another of the
tablespace deficiency.
One item of concern is that it moves the default location for new items
created, and does not move items a
At 06:07 AM 21/08/2004, Bruce Momjian wrote:
I am inclined to agree. ALTER INDEX is an operation that will happen
quite often,
One argument for doing it in this release is pg_dump/restore. Do we want
pg_dump to dump the CREATE SCHEMA followed by ALTER SCHEMA? Or will the SET
DEFAULT TABLESPACE w
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am inclined to agree. ALTER INDEX is an operation that will happen
> quite often, but I don't think ALTER SCHEMA will be as frequent, and the
> given solution doesn't address the two needs of moving the entire schema
> or just future object creation.
Marc G. Fournier wrote:
> On Fri, 20 Aug 2004, Bruce Momjian wrote:
>
> > Would people like this applied to 8.0? It addresses another of the
> > tablespace deficiency.
>
> This is an extension of tablespaces, and is not required to fix a bug ...
> therefore, it is a feature, and not eligible fo
On Fri, 20 Aug 2004, Bruce Momjian wrote:
Would people like this applied to 8.0? It addresses another of the
tablespace deficiency.
This is an extension of tablespaces, and is not required to fix a bug ...
therefore, it is a feature, and not eligible for inclusion at this point
in the developmen
Would people like this applied to 8.0? It addresses another of the
tablespace deficiency.
One item of concern is that it moves the default location for new items
created, and does not move items already created in the tablespace
itself. This conflicts with ALTER TABLE/INDEX which moves the actu
33 matches
Mail list logo
