On 15/05/10 05:15, Alvaro Herrera wrote:
Excerpts from Tom Lane's message of vie may 14 13:26:06 -0400 2010:
However, I think -C is a special case because it's quite un-obvious
to the user that it effectively acts as a filter switch --- in fact a
de-filtering switch, because the lack of
On 13/05/10 03:39, Tom Lane wrote:
Russell Smith mr-r...@pws.com.au writes:
pg_restore silently ignores the inclusion of -C when you do use a
restore list.
It would work as you expect if you use -C when creating the list file.
The reason for this is that -C basically means don't
On 13/05/10 19:26, Russell Smith wrote:
On 13/05/10 03:39, Tom Lane wrote:
Russell Smith mr-r...@pws.com.au writes:
pg_restore silently ignores the inclusion of -C when you do use a
restore list.
It would work as you expect if you use -C when creating the list file
On 03/05/10 01:30, Tom Lane wrote:
Russell Smith mr-r...@pws.com.au writes:
On 02/05/10 01:36, Tom Lane wrote:
No, that's the intended place for them given the current division of
labor between pg_dump and pg_dumpall. There have been complaints before
about this, but no one has
Hi,
pg_restore silently ignores the inclusion of -C when you do use a
restore list.
postgres$ pg_dump -Fc postgres postgres.dump
postgres$ pg_restore -C postgres.dump | grep 'CREATE DATABASE'
CREATE DATABASE postgres WITH TEMPLATE = template0 ENCODING = 'UTF8';
## Create a restore list
Hi,
I've recently upgraded to PostgreSQL 8.4 as Redhat had begun supporting
it. I have tried to dump database grants, but have only found an
obscure way to do it.
I would expect;
postgres$ pg_dump -Fc database_name backup.pgdump
would include all of the GRANT CONNECT on database_name TO
On 02/05/10 01:36, Tom Lane wrote:
Russell Smith mr-r...@pws.com.au writes:
Is this considered a bug that the only way to do a dump/restore with
database privileges is to use pg_dumpall?
No, that's the intended place for them given the current division of
labor between pg_dump
Michail Antonov wrote:
The following bug has been logged online:
Bug reference: 5319
Logged by: Michail Antonov
Email address: atin65...@gmail.com
PostgreSQL version: 8.4.2
Operating system: Windows XP
Description:recursion in the triggers
Details:
I have
and testifies to the same
problem http://www.mail-archive.com/[EMAIL PROTECTED]/msg53869.html
Thoughts?
Regards
Russell Smith
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
to get this fixed and possibly backported?
Thanks
Russell Smith
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Tom Lane wrote:
Russell Smith [EMAIL PROTECTED] writes:
In-equality transformations do not guarantee that y 1.5x == y/x
1.5. This is only true for x0, y 1.5*x for x0. I have not posted a
patch as I'm not sure what is the best way to change the example.
Seems a bit nit-picky
1.5x == y/x
1.5. This is only true for x0, y 1.5*x for x0. I have not posted a
patch as I'm not sure what is the best way to change the example.
Regards
Russell Smith
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Alvaro Herrera wrote:
Russell Smith wrote:
The issue is output, not input.
SET datestyle='dmy';
SELECT '03-03-2004'::date
Will return '2007-03-03', not 03-03-2004 as is the set datestyle.
You are aware that DateStyle controls both input and output,
_separately_, yes?
No, I've RTFM'd
Heikki Linnakangas wrote:
Randolf Richardson wrote:
After convincing clients and colleagues to switch from Oracle (and others)
to PostgreSQL, an issue that comes up is the need to customize DATESTYLE.
Because this isn't possible, the developers who were against the move to
PostgreSQL make
Alvaro Herrera wrote:
Alvaro Herrera wrote:
2. decide that the standard is braindead and just omit dumping the
grantor when it's no longer available, but don't remove
pg_auth_members.grantor
Which do people feel should be implemented? I can do whatever we
decide; if no one has a
Alvaro Herrera wrote:
Alvaro Herrera wrote:
Alvaro Herrera wrote:
2. decide that the standard is braindead and just omit dumping the
grantor when it's no longer available, but don't remove
pg_auth_members.grantor
Which do people feel should be implemented? I can do whatever we
Alvaro Herrera wrote:
Russell Smith wrote:
Alvaro Herrera wrote:
Alvaro Herrera wrote:
2. decide that the standard is braindead and just omit dumping the
grantor when it's no longer available, but don't remove
pg_auth_members.grantor
Which do people feel should
The following bug has been logged online:
Bug reference: 3265
Logged by: Russell Smith
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.4
Operating system: RHEL4
Description:8.1 - 8.2 behviour change: View owner must have access
to underlying tables
Details
achieve this anyway.
Regards
Russell Smith
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
Russell Smith wrote:
CREATE ROLE test_role
NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE;
CREATE ROLE invalid_grantor
SUPERUSER INHERIT NOCREATEDB NOCREATEROLE;
SET ROLE invalid_grantor;
GRANT postgres TO test_role;
SET ROLE postgres;
select * from pg_roles;
select pg_auth_members
Alvaro Herrera wrote:
Russell Smith wrote:
As I am not a frequent reporter of bugs, what happens now? It's been a
week since I wrote my last message and I'm unsure of whether anything
has, or is going to happen about this bug report. Alvaro has said it's
a bug, so it needs fixing
Alvaro Herrera wrote:
Russell Smith wrote:
Alvaro Herrera wrote:
Jeff Davis wrote:
CREATE ROLE test_role
NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE;
CREATE ROLE invalid_grantor
SUPERUSER INHERIT NOCREATEDB NOCREATEROLE;
SET ROLE invalid_grantor;
GRANT postgres
Alvaro Herrera wrote:
Jeff Davis wrote:
CREATE ROLE test_role
NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE;
CREATE ROLE invalid_grantor
SUPERUSER INHERIT NOCREATEDB NOCREATEROLE;
SET ROLE invalid_grantor;
GRANT postgres TO test_role;
SET ROLE postgres;
select * from pg_roles;
Tom Lane wrote:
Jens-Wolfhard Schicke [EMAIL PROTECTED] writes:
I an explain analyze I saw recently, a BitmapOr node of 5 Bitmap Index Scan
looked like this:
BitmapOr (cost=43.57..43.57 rows=1833 width=0) (actual time=0.146..0.146
rows=0 loops=1)
Can we do better than just saying
Tigran Mkrtchyan wrote:
Does it mean that I have to commit after each select statement?
Here what the manual says:
Description
COMMIT commits the current transaction. All changes made by the
transaction become visible to others and are guaranteed to be durable
if a crash
Nicholas wrote:
The following bug has been logged online:
Bug reference: 1993
Logged by: Nicholas
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.3,8.0.4,8.1
Operating system: Gentoo Linux
Description:Adding/subtracting negative time intervals changes time
break the spec in other ways.
For now I'd recommend casting the NULLs explicitly.
Can we spit out an error that is slightly more relevant? Maybe print
a warning/error that NULL was used without a type?
Regards
Russell Smith
regards, tom lane
---(end of broadcast
those two will give incorrect results. One will be
missing C, and it will be included with B,
and the other D for the same reason.
'C', --switch me
'D', -- and switch me
'E',
'F',
[snip]
Regards
Russell Smith.
---(end of broadcast)---
TIP 9
has changed as Tom has suggested, but
which is correct?
7.2, or 8.0?
Regards
Russell Smith
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
On Sat, 13 Nov 2004 04:05 pm, Tom Lane wrote:
Russell Smith [EMAIL PROTECTED] writes:
pg_dump does not fold case, and quote table and schema names correctly.
This is not a bug; it is a behavior we deliberately adopted years ago,
after unsuccessful experiments with behavior like what you
.
POSTGRESQL BUG REPORT TEMPLATE
Your name : Russell Smith
Your email address : As From address
System Configuration
-
Architecture (example: Intel Pentium
31 matches
Mail list logo