Re: [PATCHES] New pg_dump options: exclude tables/schemas, multiple
Bruce Momjian wrote: > Tom Lane wrote: > > > 3) It would require yet more arguments to pg_dump. The moment we start > > > allowing > > > regular expression characters that are also valid identifier names (e.g. > > > "." > > > and "_") we'll need some way to tell pg_dump whether we mean a literal > > > search > > > or a regular expression one. > > > > However, we are going to have that problem in spades if we do a > > half-baked pattern feature now and then want to improve it later. > > I think it'd be better to get it right the first time. > > > > In practice, I don't think that LIKE-style patterns (% and _ wildcards) > > will pose a serious compatibility problem if we just decree that the > > -n and -t switches now take patterns rather than plain names. I agree > > that regex-style patterns would open some gotchas, but what's wrong with > > standardizing on LIKE patterns? > > I am concerned about the number of object names that have an underscore. > It seems regex would have fewer conflicts, even though it has more > special characters. Sorry, I see the group came to the same conclusion. I should have read to the end of the thread. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] New pg_dump options: exclude tables/schemas, multiple
Tom Lane wrote: > > 3) It would require yet more arguments to pg_dump. The moment we start > > allowing > > regular expression characters that are also valid identifier names (e.g. "." > > and "_") we'll need some way to tell pg_dump whether we mean a literal > > search > > or a regular expression one. > > However, we are going to have that problem in spades if we do a > half-baked pattern feature now and then want to improve it later. > I think it'd be better to get it right the first time. > > In practice, I don't think that LIKE-style patterns (% and _ wildcards) > will pose a serious compatibility problem if we just decree that the > -n and -t switches now take patterns rather than plain names. I agree > that regex-style patterns would open some gotchas, but what's wrong with > standardizing on LIKE patterns? I am concerned about the number of object names that have an underscore. It seems regex would have fewer conflicts, even though it has more special characters. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] Uninstall scripts for contrib
Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --- David Fetter wrote: > On Mon, Jan 16, 2006 at 12:13:11AM -0500, Neil Conway wrote: > > On Sun, 2006-01-15 at 20:08 -0800, David Fetter wrote: > > > > > > ifdef USE_PGXS > > > > The change to $PostgreSQL$ is bogus (perhaps due to the way you > > setup cvsup?), as are all the other $PostgreSQL$ changes in the > > patch. Also, the patch doesn't actually add any files called > > "uninstall.sql". > > Oops. My FM R'ing skills need some work. This patch includes the > files. > > Cheers, > D > -- > David Fetter [EMAIL PROTECTED] http://fetter.org/ > phone: +1 415 235 3778 > > Remember to vote! [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 4: Have you searched our list archives? > >http://archives.postgresql.org -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[PATCHES] contrib/adddepend failed 8.1.2
Hi.
I was trying to upgrade PostgreSQL from 7.2.8 to 8.1.2.
Dump and restore work well. But adddepend was failed.
To fix it, this regexp
$seq =~ s|^nextval\(["']+([^'"\)]+)["']+.*\)$|$1|g;
need to change
$seq =~ s|^nextval\(\(["']+([^'"\)]+)["']+.*\)$|$1|g;
or
$seq =~ s|^nextval\(\(?["']+([^'"\)]+)["']+.*\)$|$1|g;
[EMAIL PROTECTED] adddepend]$ ./adddepend -Y -d ishida
Upgrade the Unique Constraint style via:
DROP INDEX t_i_key RESTRICT;
ALTER TABLE t ADD CONSTRAINT t_i_key UNIQUE (i);
NOTICE: ALTER TABLE / ADD UNIQUE will create implicit index "t_i_key"
for table "t"
Do you wish to upgrade Sequence 'nextval(('"t_i_seq"'::text)::regclass)'
to SERIAL?
Found on column t.i
DBD::Pg::st execute failed: ERROR: syntax error at or near ""t_i_seq""
at character 790 at ./adddepend line 539.
logfile
ERROR: syntax error at or near ""t_i_seq"" at character 790
STATEMENT:
INSERT INTO pg_catalog.pg_depend
( classid
, objid
, objsubid
, refclassid
, refobjid
, refobjsubid
, deptype
) VALUES ( (SELECT c.oid--
classid
FROM pg_class as c
JOIN pg_namespace as n
ON (n.oid =
c.relnamespace)
WHERE n.nspname = 'pg_catalog'
AND c.relname = 'pg_class')
, (SELECT c.oid-- objid
FROM pg_class as c
JOIN pg_namespace as n
ON (n.oid =
c.relnamespace)
WHERE n.nspname = 'public'
AND c.relname =
'nextval(('"t_i_seq"'::text)::regclass)')
, 0--
objsubid
, (SELECT c.oid--
refclassid
FROM pg_class as c
JOIN pg_namespace as n
ON (n.oid =
c.relnamespace)
WHERE n.nspname = 'pg_catalog'
AND c.relname = 'pg_class')
, (SELECT c.oid--
refobjid
FROM pg_class as c
JOIN pg_namespace as n
ON (n.oid =
c.relnamespace)
WHERE n.nspname = 'public'
AND c.relname = 't')
, (SELECT a.attnum --
refobjsubid
FROM pg_class as c
JOIN pg_namespace as n
ON (n.oid =
c.relnamespace)
JOIN pg_attribute as a
ON (a.attrelid = c.oid)
WHERE n.nspname = 'public'
AND c.relname = 't'
AND a.attname = 'i')
, 'i' --
deptype
);
--
ISHIDA Akio <[EMAIL PROTECTED] / [EMAIL PROTECTED]>
*** ./contrib/adddepend/adddepend.orig 2003-11-30 07:39:16.0 +0900
--- ./contrib/adddepend/adddepend 2006-01-18 00:46:32.0 +0900
***
*** 469,475
my $seq = $row->{'adsrc'};
# Extract the sequence name from the default
! $seq =~ s|^nextval\(["']+([^'"\)]+)["']+.*\)$|$1|g;
# Does the user want to upgrade this sequence?
print <{'adsrc'};
# Extract the sequence name from the default
! $seq =~ s|^nextval\(\(["']+([^'"\)]+)["']+.*\)$|$1|g;
# Does the user want to upgrade this sequence?
print <
---(end of broadcast)--
