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
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.
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
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
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 have a
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
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]
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
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
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
GUC variable
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 system
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 willing to
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 tablespace, such that all
TOAST tables would be put in the 'toastspace'. But I think the syntax is
ugly and would confuse
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
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 some
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
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 TABLESPACE
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
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 wish you
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 is plainly
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:
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
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
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 GUC
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
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 tablespace choices
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) application
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 creating a
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 sense
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 just
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 nice, but
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 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
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 decide
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,
soapbox
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 the
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.)
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 clause could
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
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 DEFINTION.
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
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
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 ALTER
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 there is no
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
46 matches
Mail list logo
