At 02:37 PM 6/11/2004, Tom Lane wrote:
If you have a preliminary patch, you could pass it along and I'll finish
it up.
Attached. It has some trivial-looking rejects on current CVS. Let me know
if you would prefer me to do the work, or want some testing done. It was
tested (in terms of output vali
Philip Warner <[EMAIL PROTECTED]> writes:
> Attached. It has some trivial-looking rejects on current CVS. Let me know
> if you would prefer me to do the work, or want some testing done. It was
> tested (in terms of output validity) with 8.0b1.
Applied with minor cleanups.
FYI, we need tablespace_default to control this pg_dump output for a
primary key:
ALTER TABLE ONLY test2
ADD CONSTRAINT test2_pkey PRIMARY KEY (x);
---
Tom Lane wrote:
> Philip Warner <[EMAIL PROTECTED]>
TODO item removed:
* Allow database recovery where tablespaces can't be created
When a pg_dump is restored, all tablespaces will attempt to be created
in their original locations. If this fails, the user must be able to
adjust the restore process.
Not done yet, but it will be with SET def
Philip Warner <[EMAIL PROTECTED]> writes:
> Time is at a serious premium for me at the moment (I have several projects
> all due about now); but I wrote a patch for this a few weeks back, so it
> should not be a lot of work (unless pg_dump has changed in the last couple
> of months).
If you hav
At 06:19 AM 6/11/2004, Tom Lane wrote:
You had muttered something about wanting to add
a TOC entry field for this --- do you still want to do the work?
You can probably get it done faster than I could, but I dunno if you
have time at the moment. I'd like to get it in over the weekend so
that we ca
Philip,
I've just committed the backend changes involved in setting up a
"default_tablespace" GUC variable for pg_dump to use, but I didn't
do anything to convert pg_dump to doing so instead of using explicit
TABLESPACE clauses. You had muttered something about wanting to add
a TOC entry field f
OK, TODO updated:
* Add a GUC variable to control the tablespace for temporary
objects
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Gavin Sherry wrote:
> >> I'm not sure about TOAST
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Gavin Sherry wrote:
>> I'm not sure about TOAST however. I considered the idea of adding
>> something to CREATE TABLE like TOASTSPACE , such that all
>> TOAST tables would be put in the 'toastspace'. But I think the syntax is
>> ugly and would confuse man
Added to open items:
* Add a GUC variable to control temporary and TOAST tablespace usage
---
Gavin Sherry wrote:
> On Sun, 31 Oct 2004, Bruce Momjian wrote:
>
> > Tom Lane wrote:
> > > I wrote:
> > > > I'd be wil
Gavin Sherry wrote:
> > One downside that came up yesterday in a discussion is that once shemas
> > don't have default tablespaces we can't easily have default tablespaces
> > for toast and temporary table system schemas. Now we can't actually do
> > that now anyway because they are created by the
On Sun, 31 Oct 2004, Bruce Momjian wrote:
> Tom Lane wrote:
> > I wrote:
> > > I'd be willing to jump this way if we can work out the
> > > default-tablespace inconsistencies that Bruce has on the open items
> > > list.
> >
> > After further thought it seems to me that using a default_tablespace
>
Tom Lane wrote:
> I wrote:
> > I'd be willing to jump this way if we can work out the
> > default-tablespace inconsistencies that Bruce has on the open items
> > list.
>
> After further thought it seems to me that using a default_tablespace
> GUC variable doesn't eliminate all the open issues. In
I wrote:
> I'd be willing to jump this way if we can work out the
> default-tablespace inconsistencies that Bruce has on the open items
> list.
After further thought it seems to me that using a default_tablespace
GUC variable doesn't eliminate all the open issues. In particular
it is no help for
Added to open items list:
* Tablespace
o add new GUC default_tablespace to control object creation when
no explicit TABLESPACE clause exists
Use it in pg_dump.
o Remove tablespace default for databases and schemas
Place objects as specified by the
Dear Tom,
ISTM that the core business of a database is to help organize and protect
data, and it is plainly that. You just wish you won't need it, so it is
somehow "abstract", but when and if you need it, it is not "second-order"
at all;-) and it is much too late to redo the dump.
So you create som
Tom Lane wrote:
> > I think a viable solution is to go with the latter (ie, for CREATE TABLE
> > foo(i int primary key) TABLESPACE ts; the index on i is created in
> > default_tablespace). However, I might be nice to be able to specify the
> > tablespace as part of the primary key clause. I say nic
Philip Warner wrote:
> At 09:28 AM 26/10/2004, Tom Lane wrote:
>
> >I can't see what a search path would be good for.
>
> Nothing at this stage.
The idea of a tablespace search path was that restores could specify a
fallback if the tablespace doesn't exist, but it seems easier for the
SET to jus
Gavin Sherry <[EMAIL PROTECTED]> writes:
> [ ... in Oracle: ]
> So, when you create a new database, you can determine where the 'system
> catalogs' are by setting the datafile location for the system catalog
> tablespaces. You can *also* set a default tablespace for the database --
> default in the
On Mon, 25 Oct 2004, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > Hmmm.. despite that problem, I was rather fond of schema default
> > tablespaces because they allow DBAs to set a policy for a particular
> > schema. The cases I've discussed with people so far are things
> > like
Gavin Sherry <[EMAIL PROTECTED]> writes:
> Hmmm.. despite that problem, I was rather fond of schema default
> tablespaces because they allow DBAs to set a policy for a particular
> schema. The cases I've discussed with people so far are things
> like creating a schema for a (closed source) applicat
On Mon, 25 Oct 2004, Tom Lane wrote:
> Philip Warner <[EMAIL PROTECTED]> writes:
> > At 08:00 AM 26/10/2004, Tom Lane wrote:
> >> I don't want a GUC variable that actively changes the default
> >> tablespace; at least not unless you want to abandon the current
> >> mechanisms for default tablespac
At 09:28 AM 26/10/2004, Tom Lane wrote:
I can't see what a search path would be good for.
Nothing at this stage.
It seems like we still need some notion of a database's schema,
Yes.
I'd be willing to jump this way if we can work out the
default-tablespace inconsistencies that Bruce has on the ope
Philip Warner <[EMAIL PROTECTED]> writes:
> At 08:00 AM 26/10/2004, Tom Lane wrote:
>> I don't want a GUC variable that actively changes the default
>> tablespace; at least not unless you want to abandon the current
>> mechanisms for default tablespace choices entirely, and go over to
>> making the
At 08:00 AM 26/10/2004, Tom Lane wrote:
I don't want a GUC variable that actively changes the default
tablespace; at least not unless you want to abandon the current
mechanisms for default tablespace choices entirely, and go over to
making the GUC variable be the sole arbiter.
Something consistent
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I am confused. I thought Tom's argument was that we shouldn't add an
> > overly complex tablespace SET variable just to prevent the non-standard
> > TABLESPACE in CREATE, which I can understand. However, the text above
> > seems to i
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am confused. I thought Tom's argument was that we shouldn't add an
> overly complex tablespace SET variable just to prevent the non-standard
> TABLESPACE in CREATE, which I can understand. However, the text above
> seems to indicate we don't need an '
Tom Lane wrote:
> Fabien COELHO <[EMAIL PROTECTED]> writes:
> > I disagree on the view that being able to restore a database on another
> > machine after a crash is an "abstract second-order goal";-)
>
> > ISTM that the core business of a database is to help organize and protect
> > data, and it
Fabien COELHO <[EMAIL PROTECTED]> writes:
> I disagree on the view that being able to restore a database on another
> machine after a crash is an "abstract second-order goal";-)
> ISTM that the core business of a database is to help organize and protect
> data, and it is plainly that. You just w
Dear Tom,
[...]
This combines the idea of pulling the TABLESPACE specification out of
the CREATE, and allows a fallback if the primary tablespace doesn't
exist.
... and takes us even further away from the notion that the default
tablespace is determined by the parent object (database or schema).
I
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I was thinking we could have a var like schema search path that
> specifies where we try to create the object:
> SET tablespace_path = 'tblspc1, pg_default';
> CREATE TABLE test(x int);
> This combines the idea of pulling the TABLESP
Philip Warner wrote:
> If we can adopt the move-after-create solution, then we really only have
> two options:
>
> - virtual tablespaces (which do seem kind of useful, especially for
> development vs. production config where the local/personal dev version
> can use the same script as a
At 12:38 PM 25/10/2004, Bruce Momjian wrote:
o Anything that works only for pg_restore and hence doesn't
work for ASCII dumps isn't an acceptable solution
Agree; but don't forget that an ascii dump is implemented almost
identically to "pg_dump | pg_restore", so when I refer to
I have read through this thread hoping that a solution would be found
but I see we are still poking. My ideas:
o Anything that works only for pg_restore and hence doesn't
work for ASCII dumps isn't an acceptable solution
o Creating the tablespaces before the dump is
At 05:41 AM 21/10/2004, Robert Treat wrote:
I've been thinking of an alternative solution that sounds very similar
to this. The idea is to output the CREATE TABLESPACE commands inside
pg_dump
...
1) tablespace already exists
to fail, but since we no longer stop on error during restore,
A fact
On Tue, 2004-10-19 at 21:06, Philip Warner wrote:
> At 04:20 AM 20/10/2004, Tom Lane wrote:
> >Nope. I can break that trivially, eg:
>
> Thats why in my first message I mentioned escaping and unescaping all '%'
> in the deinition.
>
>
> >There's also the nontrivial matter of how pg_dump would
At 04:20 AM 20/10/2004, Tom Lane wrote:
Nope. I can break that trivially, eg:
Thats why in my first message I mentioned escaping and unescaping all '%'
in the deinition.
There's also the nontrivial matter of how pg_dump would decide where to
insert the %%tablespace%% string into the CREATE INDE
Philip Warner <[EMAIL PROTECTED]> writes:
> DEFINITION: CREATE TABLE fred ... %%tablespace%% ...
> TABLESPACE: ' TABLESPACE t'
> pg_restore would read these, and use the settings from the command line to
> either substitute an empty string or the TABLESPACE text for %%tablespace%%
> in the DEFIN
At 03:25 AM 20/10/2004, Tom Lane wrote:
Maybe there's something I don't understand. How are you expecting
pg_restore to control whether it outputs the command with a TABLESPACE
clause embedded or not, if pg_dump has already built the command string
that way?
This will only work if we modify the du
Philip Warner <[EMAIL PROTECTED]> writes:
> At 03:06 AM 20/10/2004, Tom Lane wrote:
>> I think the tricky part of that would be inserting the tablespace clause
>> in the right place; for CREATE INDEX this seems to require nontrivial
>> parsing. (Both the index column definitions and the WHERE clau
At 03:06 AM 20/10/2004, Tom Lane wrote:
I think the tricky part of that would be inserting the tablespace clause
in the right place; for CREATE INDEX this seems to require nontrivial
parsing. (Both the index column definitions and the WHERE clause could
be arbitrarily complicated expressions.) If
Philip Warner <[EMAIL PROTECTED]> writes:
> To solve this, we should dump the table definition as a format string and
> dump the tablespace clause (ie. ' TABLESPACE ts') as a separate part of the
> table definition TOC entry. If the user wants the tablespace to be dumped,
> then we substitute th
At 03:15 AM 19/10/2004, Bruce Momjian wrote:
The only downside is that it prevents SQL-compliant CREATE syntax in
dumps.
One idea that may be worth considering: we currently dump a complete SQL
statement including a TABLESPACE clause, which makes it hard to allow
pg_restore to have a 'no tablespa
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > One additional idea for this item is to use CREATE to first create the
> > object, then move it using ALTER, and the ALTER might fail if the
> > tablespace doesn't exist.
>
> This seems fairly impractical, at least for indexes where t
Bruce Momjian <[EMAIL PROTECTED]> writes:
> One additional idea for this item is to use CREATE to first create the
> object, then move it using ALTER, and the ALTER might fail if the
> tablespace doesn't exist.
This seems fairly impractical, at least for indexes where there is no
way to do the ALT
One additional idea for this item is to use CREATE to first create the
object, then move it using ALTER, and the ALTER might fail if the
tablespace doesn't exist. The only problem with that is this TODO item:
o Allow databases and schemas to be moved to different tablespaces
One
46 matches
Mail list logo
