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 l
On 15/05/10 03:26, Tom Lane wrote:
> Russell Smith writes:
>
>>> By the operation of other items (-C --data-only) passed with -l, it only
>>> produces to contents that would be restored with the other switches
>>> provided. If that's expect behavior, th
On 13/05/10 19:26, Russell Smith wrote:
> On 13/05/10 03:39, Tom Lane wrote:
>
>> Russell Smith writes:
>>
>>
>>> pg_restore silently ignores the inclusion of -C when you do use a
>>> restore list.
>>>
>>>
>>
On 13/05/10 03:39, Tom Lane wrote:
> Russell Smith 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 b
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
postgre
On 03/05/10 01:30, Tom Lane wrote:
> Russell Smith 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 complai
On 02/05/10 01:36, Tom Lane wrote:
> Russell Smith 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 divisio
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 "Rol
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:
>
Annita Veneti wrote:
> Matt you are absolutely right! The msysconf is not related...
> Yesterday I did some test and have seen that the access is working fine with
> postgres as long as the SSL mode is disable, as soon as I put it enabled then
> it crashes on shutdown
>
> Go figure!!!
>
> Any
Hemavathi B N wrote:
> The following bug has been logged online:
>
> Bug reference: 4393
> Logged by: Hemavathi B N
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.0
> Operating system: windows 2003
> Description:failed toget system metics for terminal servic
[EMAIL PROTECTED] wrote:
> select ats.id, ap.value from akh_test_suit ats
> LEFT JOIN akh_properties ap on ap.ID = ats.test_suit_type_id
> where ats.ID = 472
>
> id | value
> 472 | 472
> ID -- integer
> value -- text
>
>
> select * from akh_test_suit ats
> LEFT JOIN akh_properties ap on ap.ID
t reaches 0 then
call CRYPT_set_xx_callback(NULL) to remove the callbacks. This is a
windows SSL thread that crashes iexplore 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
Russell Smith wrote:
> Hi,
>
> After experiencing a seg fault on RHEL5's command line php, I did the
> following investigation.
>
> As I dot not have a RHEL5 box available with debugging tools, I
> reproduced the bug on CentOS5.
Hi,
I've not received any feedback on
gsql.php:3
Stack trace:
#0 /root/test-pgsql.php(3): PDO->__construct('pgsql:host=thoe...', 'nouser',
'nopass')
#1 {main}
thrown in /root/test-pgsql.php on line 3
As a result, the crash has gone away. Are the comments in the PHP
comment accurate and is it re
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 x>0, y < 1.5*x for x<0. I have not posted a
patch as I'm not sure what is the best way to change the examp
ormations do not guarantee that y > 1.5x == y/x >
1.5. This is only true for x>0, y < 1.5*x for x<0. 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)
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,
_separatel
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:
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
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:
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 stro
Tom Lane wrote:
"Russell Smith" <[EMAIL PROTECTED]> writes:
CREATE view v1 as select * from t1;
ALTER TABLE v1 OWNER TO "USER";
See thread here:
http://archives.postgresql.org/pgsql-hackers/2006-04/msg01138.php
and patch here:
http://archives.postgresql.or
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
Deta
by any role, as
if you drop and recreate the object you can 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
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&
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;
se
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 "postgre
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 sayi
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 occurs.
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
z
immediately). While we'd like to accept it, we have
> not figured out a rule that doesn't 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 wa
t.propname = 'T' THEN 'Err'
> WHEN t.propname = 'U' THEN 'Rm'
> WHEN t.propname = 'V' THEN 'Tm'
> WHEN t.propname = 'W' THEN 'Tm'
> ELSE t.propname
> END as
f anything needs to be changed here, it's the behavior of round(numeric).
>
So I would say that the round behaviour 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
this form.
POSTGRESQL BUG REPORT TEMPLATE
Your name : Russell Smith
Your email address : As From address
System Configuration
-
Architecture (exam
37 matches
Mail list logo
