On Wed, Aug 18, 2004 at 10:12:53PM -0400, Bruce Momjian wrote:
Magnus Hagander wrote:
Another discussion was about binary files in the tree (not being source
files - the source is a binary .AI file (AFAIK that's Adobe
Illustrator)). The question was raised wether ImageMagick could do
How about an environment variable that points to a .pgpass type file.
You can do that today: point $HOME at some temp directory or other.
AFAIR pg_dump doesn't make any other use of $HOME ...
Or we could even play games with PGPASSWORD - if it names an
existing file
that satisfies the .pgpass
IIRC there was discussion about the location of the files
(Peter I think
it was suggesting creating a new directory - I'll happily leave that
part up to an eventual committer).
Another discussion was about binary files in the tree (not
being source
files - the source is a binary .AI file
If the location doesn't exist will postgresql try to create it? istm
it could do this and if it fails then you are no worse off, but if it
were to succeed you're that much better off.
Yea, I assume if you can't create the tablespace you put everything for
that tablespace in the default
hi all,
I am porting all my data from oracle to postgres :) . I want
to know where can I put the tables which existed in nulltablespace in
oracle. How is the nullTablespace different from default table space
and how is this done in postgres .
--
Stand for something, or you will fall for
Dear Bruce,
Bruce - pg_dump TODO for --no-tablespace or something?
Uh, TODO already has:
* 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
Christopher Kings-Lynne wrote:
It's deprecated because it's insecure, on platforms where other users can
see the environment variables passed to pg_dump (which apparently is
quite a few variants of Unix). You wouldn't pass the password on the
command line either ...
Painful as .pgpass may be for
In point of fact I think this discussion is much ado about nothing, as
there is already a workaround
Just call that a kludge as it means that the admin is expected to create
as many dummy and unknown (if you have a custom dump file) tablespaces as
necessary to please pg_restore.
These
Gavin Sherry wrote:
On Wed, 18 Aug 2004, Gaetano Mendola wrote:
Gavin Sherry wrote:
On Wed, 18 Aug 2004, Gaetano Mendola wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
now that we have the tablespace support don't you think that
each tablespace needs his own costs instead of a
On Wed, 2004-08-18 at 02:48, Greg Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
This behaviour allows much closer mimicking of Oracle and other RDBMS's
transactional behaviour
begin 2cThis is my single biggest pet peeve with Postgres. When I was first
starting it was the single
Magnus Hagander said:
How about an environment variable that points to a .pgpass type file.
So let's go woth PGPASSFILE
How about --pwfile on the commandline, the same way initdb does it?
Then you can't make it part of libpq - you would have to build it into every
program that needs it.
Hi Every one.
At least I made PITR working however I still have 2 questions:
1) It seems there is a slight bug in this case:
select pg_backup_start('test);
... make backup
select pg_backup_end();
psql database
drp table note the time in logs
pg_ctl stop
rm -rf $PGDATA
restore backup
put the
Fabien COELHO [EMAIL PROTECTED] writes:
Just call that a kludge as it means that the admin is expected to create
as many dummy and unknown (if you have a custom dump file)
tablespaces
There are any number of ways to find it out --- read the output of
pg_restore -s, or just try the restore and
I never got any feedback on v7.3.7's packaging, so I'm guessing that it
looked okay to everyone, even though it was substantially smaller? The
only two things that I can think of that might have failed appear to be in
there:
%tar tvzpf postgresql-7.3.7.tar.gz | grep man.tar
-rw-r--r--
At 12:21 AM 20/08/2004, Tom Lane wrote:
You can give it a new paint job in 8.1, if you like.
To side-step the issue, is there a tablespace equivalent of a default schema?
Could we 'set default tablespace xxx', then have pg_dump/restore use a
'create table' that does not refer to the tablespace?
Marc G. Fournier [EMAIL PROTECTED] writes:
I never got any feedback on v7.3.7's packaging, so I'm guessing that it
looked okay to everyone, even though it was substantially smaller?
Devrim pointed out yesterday that it seemed to be missing
contrib/earthdistance; that's not enough to explain
Nope, and I even checked jdbc to make sure nothing go screwed up with the
moves post-7.3, and its there also ... and 7.2 *appears* to be okay size
wise ...
On Thu, 19 Aug 2004, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
I never got any feedback on v7.3.7's packaging, so I'm
Marc G. Fournier [EMAIL PROTECTED] writes:
I just got 7.2.5 done now ... I pulled the man.tar.gz file from 7.2.4 and
put a copy of it into ~ftp/pub/dev/doc/man-7.2.tar.gz (in case its needed
in the future) ...
The 7.2.5 tarball is considerably bigger than 7.2.4; this seems to be
because the
Marc G. Fournier [EMAIL PROTECTED] writes:
I never got any feedback on v7.3.7's packaging, so I'm guessing that it
looked okay to everyone, even though it was substantially smaller?
I diff'd the 7.3.6 and 7.3.7 tarballs, and got these unexpected
differences:
Only in
One other little problem with the 7.2.5 package: I see you rebuilt the
flex and bison output files with our current versions of those tools.
I think this is probably okay, but it changes the expected output of
some of the regression tests, eg
*** ./expected/strings.out Fri Jun 1 13:49:17
Tom Lane wrote:
Fabien COELHO [EMAIL PROTECTED] writes:
Just call that a kludge as it means that the admin is expected to create
as many dummy and unknown (if you have a custom dump file)
tablespaces
There are any number of ways to find it out --- read the output of
pg_restore -s, or
The good news is that the 7.4.5 package looks right ;-)
regards, tom lane
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Philip Warner wrote:
At 12:21 AM 20/08/2004, Tom Lane wrote:
You can give it a new paint job in 8.1, if you like.
To side-step the issue, is there a tablespace equivalent of a default schema?
Could we 'set default tablespace xxx', then have pg_dump/restore use a
'create table' that does
Dear Tom,
as many dummy and unknown ... tablespaces
There are any number of ways to find it out --- read the output of
pg_restore -s, or just try the restore and observe the errors.
Ok, you're right on this point.
But I'm looking for something cleaner than grepping pg_restore output...
Bruce Momjian wrote:
Added to open items:
* Fix Solaris for single-host netmasks in pg_hba.conf, use CIDR?
At this stage of the game I would just change pg_hba.conf.sample to use
'127.0.0.1/32' instead of '127.0.0.1 255.255.255.255'. No need for a
Solaris-specific fix for the default setup
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
On that, note that I specifically removed jdbc and tcl options from the
spec file because the 8.0.0 release notes said they were removed from
the distribution. I suppose at lease jdbc should be put back? It didn't
seem right to include the
Andrew Dunstan [EMAIL PROTECTED] writes:
At this stage of the game I would just change pg_hba.conf.sample to use
'127.0.0.1/32' instead of '127.0.0.1 255.255.255.255'.
Yeah, that's probably the path of least resistance. Note that the
comments and possibly the SGML docs need to be adjusted to
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
At this stage of the game I would just change pg_hba.conf.sample to use
'127.0.0.1/32' instead of '127.0.0.1 255.255.255.255'.
Yeah, that's probably the path of least resistance. Note that the
comments and possibly the SGML docs
I'm seeing the following errors after a few hours of fairly aggressive
bulk load of a database running on Postgres 7.4.2:
cyspec=# select version();
ERROR: root page 43 of pg_proc_proname_args_nsp_index has level 0,
expected 2
cyspec=# select * from pg_class;
ERROR: root page 3 of
Joe Conway [EMAIL PROTECTED] writes:
I'm seeing the following errors after a few hours of fairly aggressive
bulk load of a database running on Postgres 7.4.2:
cyspec=# select version();
ERROR: root page 43 of pg_proc_proname_args_nsp_index has level 0,
expected 2
[ scratches head... ]
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
I'm seeing the following errors after a few hours of fairly aggressive
bulk load of a database running on Postgres 7.4.2:
cyspec=# select version();
ERROR: root page 43 of pg_proc_proname_args_nsp_index has level 0,
expected 2
[ scratches
I've just done a re-export of teh CVS for 7.3.7 ... this time,
earthdistance appears to be in there properly ... not sure what happened,
but am building a new package for it, and will check sizes again when
finished ...
On Thu, 19 Aug 2004, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED]
On Thu, 19 Aug 2004, Tom Lane wrote:
One other little problem with the 7.2.5 package: I see you rebuilt the
flex and bison output files with our current versions of those tools.
I think this is probably okay, but it changes the expected output of
some of the regression tests, eg
***
On Thu, 19 Aug 2004, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
I never got any feedback on v7.3.7's packaging, so I'm guessing that it
looked okay to everyone, even though it was substantially smaller?
I diff'd the 7.3.6 and 7.3.7 tarballs, and got these unexpected
differences:
there, this one looks *much* better ... a couple of k smaller still:
%ls -lt postgresql-7.3.7.tar.gz ../v7.3.6/postgresql-7.3.6.tar.gz
-rw-r--r-- 1 pgsql pgsql 11284024 Aug 19 16:27 postgresql-7.3.7.tar.gz
-rw-r--r-- 1 pgsql pgsql 11288430 Mar 4 21:35 ../v7.3.6/postgresql-7.3.6.tar.gz
On
On Thu, 19 Aug 2004, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
I just got 7.2.5 done now ... I pulled the man.tar.gz file from 7.2.4 and
put a copy of it into ~ftp/pub/dev/doc/man-7.2.tar.gz (in case its needed
in the future) ...
The 7.2.5 tarball is considerably bigger than
Marc G. Fournier [EMAIL PROTECTED] writes:
Let's go with the updated regression outputs ... probably better then
going and reverting down flex/bison just for packaging :(
That's what I thought too. Patches committed --- rewrap whenever you
have a chance.
regards, tom
Marc G. Fournier [EMAIL PROTECTED] writes:
The section for docs is:
cd doc/src
gmake postgres.tar.gz
mv postgres.tar.gz ..
cp /var/spool/ftp/pub/dev/doc/man-7.3.tar.gz ../man.tar.gz
cd ../..
gmake split-dist=yes dist
gmake maintainer-clean
Shouldn't there be a gmake clean in there before
Marc G. Fournier [EMAIL PROTECTED] writes:
'k, I'm blind ... build scripts for both 7.2 and 7.3 are identical, except
for which man.tar.gz it pulls in, and what directories in ftp they get
written to ...
Oh, I see the problem. In doc/Makefile, recent versions pass the make
distclean
Marc G. Fournier [EMAIL PROTECTED] writes:
there, this one looks *much* better ... a couple of k smaller still:
The 7.3.7 tarball looks good to me too. 2 down, 1 to go ...
regards, tom lane
---(end of broadcast)---
TIP 6:
I had a problem with this patch. By removing the comment from 'port',
the postgresql.conf 'port' value is used in the regression tests rather
than the environment value. I see in guc.c
env = getenv(PGPORT);
if (env != NULL)
SetConfigOption(port, env, PGC_POSTMASTER,
Bruce Momjian [EMAIL PROTECTED] writes:
By removing comments from postgresql.conf, I am afraid we are making all
environment value useless.
Good point.
I suppose the easiest fix would be to re-command the postgresql.conf
values that can be over-ridden with environment variables, or make
Joe Conway writes
I'm seeing the following errors after a few hours of fairly aggressive
bulk load of a database running on Postgres 7.4.2:
When I say aggressive, I mean up to 6 simultaneous COPY processes. It is
different from the issue Tom solved the other day in that we don't get
Tom,
Right at the moment my feeling is that there are issues here that are
considerably more subtle than we realized, and rather than risk creating
unforeseen problems, we ought to bounce the whole issue back to the TODO
list for 8.1.
Agreed. I will submit a new patch that simply adds a
Simon Riggs wrote:
Joe Conway writes
I'm seeing the following errors after a few hours of fairly aggressive
bulk load of a database running on Postgres 7.4.2:
When I say aggressive, I mean up to 6 simultaneous COPY processes. It is
different from the issue Tom solved the other day in that we
Josh Berkus wrote:
Tom,
Right at the moment my feeling is that there are issues here that are
considerably more subtle than we realized, and rather than risk creating
unforeseen problems, we ought to bounce the whole issue back to the TODO
list for 8.1.
Agreed. I will submit a new
Tom Lane wrote:
Oh, I see the problem. In doc/Makefile, recent versions pass the
make distclean operation down to doc/src, but 7.2's doesn't.
Peter, any idea why it was like that back then?
The doc tree isn't built by default, so I guess no one had ever thought
of cleaning it by default,
Hi all,
It seems that there is no way to know the postgres
uptime, a sort of uptime() function could be usefull.
I had recently the necessity of detect a node fail over,
and the only way I can do it with a SQL connection is asking
the engine uptime. Of course I can do it with PS but
now that
On Thu, 19 Aug 2004, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
'k, I'm blind ... build scripts for both 7.2 and 7.3 are identical, except
for which man.tar.gz it pulls in, and what directories in ftp they get
written to ...
Oh, I see the problem. In doc/Makefile, recent versions
Marc G. Fournier [EMAIL PROTECTED] writes:
Done, and done ... sizes look alot better now:
Almost there, but you didn't pick up my regression test patches :-(
Also, I still see these in the top directory of the full tarfile:
-rw-r--r-- 1 tglusers 70 Aug 19 19:47
* Tom Lane [EMAIL PROTECTED] [gmane.comp.db.postgresql.devel.general]:
Andreas Krennmair [EMAIL PROTECTED] writes:
creating template1 database in data/base/1 ... FATAL: XX000: failed to
initialize lc_monetary to C
LOCATION: InitializeGUCOptions, guc.c:2337
child process exited with
Since I needed this feature badly, I added the -n / --schema switch to
pg_restore. It restores the given schemaname only. It can be used in
conjunction with the -t and other switches to make the selection very
fine grained.
This patches works for me, but it could use more testing.
Please Cc me
Christopher Kings-Lynne wrote:
Thanks for your response, but this is what I get:
column, Type, and Modifiers
+
Indexes and foreign key contraints.
No triggers.
It lists triggers. Trust me, I wrote it.
(Sorry for late response)
Hi Chris,
You wrote it?!?
Ok, in that case I'll better
Friends,
I would like to know if PostgreSQL can run as a Distributed Data Base
Management System. Is possible, throught PostgreSQL, to implement
horizontal partition, this is, to fragment tables horizontally?
For example, can I have a Data Base with 1 table, where it is
horizontally fragmented
Seems to me you are hacking on way more than you want to. Take another
look at your design and see if there isn't a smaller design struggling
to get out. In particular, why are you touching any of the executor
(which hardly deals in column names at all) rather than implementing the
aliasing
Clinging to sanity, [EMAIL PROTECTED] (Shahbaz Javeed) mumbled into her beard:
# This message was accidentally sent only to Bruce. It's pasted here
for comment from the rest of the list too :)
Folks,
While on the topic of Ingres and open source, I was wondering
whether there's interest in
Andreas Krennmair [EMAIL PROTECTED] writes:
The first fix is that PostgreSQL relies on that, when reading the output
of postgres -V, all the output can be read with a single read call (or
whatever call is used, it comes down to read(2) in the end) when called
from initdb.
Hmm. This is a fair
On Thursday 19 August 2004 16:04, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
Let's go with the updated regression outputs ... probably better then
going and reverting down flex/bison just for packaging :(
That's what I thought too. Patches committed --- rewrap whenever you
If you want to proceed, let me know and I'll commit the updated
regression outputs into the 7.2 branch, and then we can re-wrap.
Let's go with the updated regression outputs ... probably better then
going and reverting down flex/bison just for packaging :(
What about people who are parsing the
It seems that there is no way to know the postgres
uptime, a sort of uptime() function could be usefull.
I had recently the necessity of detect a node fail over,
and the only way I can do it with a SQL connection is asking
the engine uptime. Of course I can do it with PS but
now that windows
At 02:33 AM 20/08/2004, Bruce Momjian wrote:
Could we 'set default tablespace xxx', then have pg_dump/restore use a
'create table' that does not refer to the tablespace?
That is what I was assuming. You can't retroactively change the dump
file during restore so we would have some SET varaiable
Philip Warner wrote:
At 02:33 AM 20/08/2004, Bruce Momjian wrote:
Could we 'set default tablespace xxx', then have pg_dump/restore use a
'create table' that does not refer to the tablespace?
That is what I was assuming. You can't retroactively change the dump
file during restore so we
On Thu, 19 Aug 2004, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
Done, and done ... sizes look alot better now:
Almost there, but you didn't pick up my regression test patches :-(
Fixed ...
Also, I still see these in the top directory of the full tarfile:
-rw-r--r-- 1 tgl
At 12:37 PM 20/08/2004, Bruce Momjian wrote:
But that doesn't fix ascii dumps loaded via psql.
It does; the ascii dump file is generated by exactly the same technique as
pg_restore.
Internally, pg_dump builds a TOC, then calls RestoreArchive to dump the
text. It was designed this way for a
On Fri, Aug 20, 2004 at 09:43:13AM +0800, Christopher Kings-Lynne wrote:
It seems that there is no way to know the postgres
uptime, a sort of uptime() function could be usefull.
I had recently the necessity of detect a node fail over,
and the only way I can do it with a SQL connection is
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
What about people who are parsing the error messages?
Does anyone really have an application that is looking specifically for
parse error? And is going to do something useful when it finds it
that it would not do with an unrecognized error
Added to TODO:
* Add a function that returns the 'uptime' of the postmaster
---
Alvaro Herrera wrote:
On Fri, Aug 20, 2004 at 09:43:13AM +0800, Christopher Kings-Lynne wrote:
It seems that there is no way to
On Thu, 19 Aug 2004, Alvaro Herrera wrote:
On Fri, Aug 20, 2004 at 09:43:13AM +0800, Christopher Kings-Lynne wrote:
It seems that there is no way to know the postgres
uptime, a sort of uptime() function could be usefull.
I had recently the necessity of detect a node fail over,
and the
Philip Warner [EMAIL PROTECTED] writes:
At 12:37 PM 20/08/2004, Bruce Momjian wrote:
But that doesn't fix ascii dumps loaded via psql.
It does; the ascii dump file is generated by exactly the same technique as
pg_restore.
Right. Philip's suggestion would essentially use the same technique
On Fri, 20 Aug 2004, Gavin Sherry wrote:
On Thu, 19 Aug 2004, Alvaro Herrera wrote:
On Fri, Aug 20, 2004 at 09:43:13AM +0800, Christopher Kings-Lynne wrote:
It seems that there is no way to know the postgres
uptime, a sort of uptime() function could be usefull.
I had recently the necessity of
At 01:09 PM 20/08/2004, Tom Lane wrote:
It seemed like a reasonable idea to me...
Do we have a SET DEFAULT TABLESPACE? Can we add one for this release? If
not, we probably need to go with the ALTER TABLE. Although a SET DEFAULT
TABLESPACE would be convenent in general.
Marc G. Fournier wrote:
On Fri, 20 Aug 2004, Gavin Sherry wrote:
On Thu, 19 Aug 2004, Alvaro Herrera wrote:
On Fri, Aug 20, 2004 at 09:43:13AM +0800, Christopher Kings-Lynne
wrote:
It seems that there is no way to know the postgres uptime, a sort
of uptime() function could be usefull.
Alvaro Herrera [EMAIL PROTECTED] writes:
Is the uptime kept internally anywhere? Or even the start time?
No, and no (at least not in any globally accessible variable).
If it is, it would be quite trivial to provide access to it
Not really --- in the EXEC_BACKEND case, we'd have to do
On Fri, Aug 20, 2004 at 01:26:39PM +1000, Philip Warner wrote:
At 01:09 PM 20/08/2004, Tom Lane wrote:
It seemed like a reasonable idea to me...
Do we have a SET DEFAULT TABLESPACE? Can we add one for this release? If
not, we probably need to go with the ALTER TABLE. Although a SET DEFAULT
Alvaro Herrera wrote:
On Fri, Aug 20, 2004 at 01:26:39PM +1000, Philip Warner wrote:
At 01:09 PM 20/08/2004, Tom Lane wrote:
It seemed like a reasonable idea to me...
Do we have a SET DEFAULT TABLESPACE? Can we add one for this release? If
not, we probably need to go with the ALTER
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Is the uptime kept internally anywhere? Or even the start time?
No, and no (at least not in any globally accessible variable).
If it is, it would be quite trivial to provide access to it
Not really --- in the EXEC_BACKEND case,
Alvaro Herrera [EMAIL PROTECTED] writes:
The problem with ALTER TABLE is that it can be hugely expensive, I think.
As long as you did it before loading any data, it wouldn't be too bad.
But certainly a preceding SET would be cheaper than pushing even
zero-size files around.
I don't have any
On Thu, 19 Aug 2004, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Is the uptime kept internally anywhere? Or even the start time?
No, and no (at least not in any globally accessible variable).
If it is, it would be quite trivial to provide access to it
Not really --- in the
Marc G. Fournier wrote:
On Thu, 19 Aug 2004, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Is the uptime kept internally anywhere? Or even the start time?
No, and no (at least not in any globally accessible variable).
If it is, it would be quite trivial to provide access
At 01:47 PM 20/08/2004, Tom Lane wrote:
But someone
needs to take a close look at pg_dump's logic to see if this can work.
Not sure where the issues lie, but anything that can reside in a tablespace
(table, index,...anything else?), needs to dump it's definition without
reference to a
Marc G. Fournier [EMAIL PROTECTED] writes:
On Thu, 19 Aug 2004, Tom Lane wrote:
I'd like to see more than one person requesting this (and with solider
rationales) before it gets added to TODO. If I wanted to be picky I
would suggest that knowledge of the server start time might be useful
Marc G. Fournier [EMAIL PROTECTED] writes:
On Fri, 20 Aug 2004, Gavin Sherry wrote:
However, I'm not sure why an uptime is all that useful?
Bragging rights? :)
The folks who have a legitimate interest in that number can surely find
it out from ps. What I'm having a hard time with here is the
One point here is the handling of index tablespaces. I added TABLESPACE
as part of pg_get_indexdef output, but we'd need a different solution
if we want to go down this path. Maybe it's not a problem given this
idea about where pg_dump is going to specify tablespace. But someone
needs to take a
What have I missed? I can do the pg_dump stuff if noone else wants to.
I'm all of a sudden really busy :( Extra karate at nights + new
responsibilities at work, so my plan on doing the stuff listed for
pg_dump under TODO (specifically comments on index and composite type
columns) is rather
On Fri, 20 Aug 2004, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
On Thu, 19 Aug 2004, Tom Lane wrote:
I'd like to see more than one person requesting this (and with solider
rationales) before it gets added to TODO. If I wanted to be picky I
would suggest that knowledge of the
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
One point here is the handling of index tablespaces. I added TABLESPACE
as part of pg_get_indexdef output, but we'd need a different solution
if we want to go down this path.
Another parameter to pg_get_indexdef() :(
Actually I think we'd
On Fri, 20 Aug 2004, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
On Fri, 20 Aug 2004, Gavin Sherry wrote:
However, I'm not sure why an uptime is all that useful?
Bragging rights? :)
The folks who have a legitimate interest in that number can surely find
it out from ps. What I'm
At 02:27 PM 20/08/2004, Tom Lane wrote:
Actually I think we'd just revert the ruleutils.c
Just to confirm; it's only tables and indexes that have tablespaces, and I
can issue some kind of SET command. Any idea of the syntax?
As an aside: should a database be allowed to have a default tablespace?
Marc G. Fournier [EMAIL PROTECTED] writes:
Good point(s) ... but, what would that give an attacker? Being able to
isolate the random seed, that is?
Well, the random seed determines the salt values that will be used to
challenge password logins. So it might help you execute a
password-replay
Philip Warner [EMAIL PROTECTED] writes:
Just to confirm; it's only tables and indexes that have tablespaces, and I
can issue some kind of SET command. Any idea of the syntax?
As an aside: should a database be allowed to have a default tablespace?
Well, tables and indexes definitely have
Actually I think we'd just revert the ruleutils.c change that showed
TABLESPACE in pg_get_indexdef. The real question is to be sure that
pg_dump could get along without it. If Philip wants to fix pg_dump,
I'm content to just stay out of his way ;-)
Well my original patch did without it, someone
We already have some TODO items about sorting out exactly how the
defaulting behavior works here. In particular, what if anything is the
difference between a child object inheriting a default tablespace TS,
and explicitly saying TABLESPACE TS in its definition? If we attempt
to reload this mess
92 matches
Mail list logo
