Florian Pflug wrote:
> On Oct27, 2011, at 23:02 , Bruce Momjian wrote:
> > Florian Pflug wrote:
> >> On Oct21, 2011, at 16:42 , Phil Sorber wrote:
> >>> If you did want to make them immutable, I also like Florian's idea of
> >>> a dependency graph. This would make the dumps less readable though.
>
On Oct27, 2011, at 23:02 , Bruce Momjian wrote:
> Florian Pflug wrote:
>> On Oct21, 2011, at 16:42 , Phil Sorber wrote:
>>> If you did want to make them immutable, I also like Florian's idea of
>>> a dependency graph. This would make the dumps less readable though.
>>
>> Hm, I kinda reversed my op
Florian Pflug wrote:
> On Oct21, 2011, at 16:42 , Phil Sorber wrote:
> > If you did want to make them immutable, I also like Florian's idea of
> > a dependency graph. This would make the dumps less readable though.
>
> Hm, I kinda reversed my opinion on that, though - i.e., I no longer think
> tha
On Oct21, 2011, at 16:42 , Phil Sorber wrote:
> If you did want to make them immutable, I also like Florian's idea of
> a dependency graph. This would make the dumps less readable though.
Hm, I kinda reversed my opinion on that, though - i.e., I no longer think
that the dependency graph idea has m
On Wed, Oct 19, 2011 at 7:46 PM, Florian Pflug wrote:
> On Oct20, 2011, at 01:19 , Tom Lane wrote:
>> Florian Pflug writes:
>>> Taking this even further, why do we bother with non-immutable (i.e.,
>>> depending on the database's contents) checks during ALTER ROLE/DATABASET SET
>>> at all?
>>
>> Y
On Oct20, 2011, at 01:19 , Tom Lane wrote:
> Florian Pflug writes:
>> Taking this even further, why do we bother with non-immutable (i.e.,
>> depending on the database's contents) checks during ALTER ROLE/DATABASET SET
>> at all?
>
> Yeah, I was wondering about that one too. It would not solve a
Florian Pflug writes:
> Taking this even further, why do we bother with non-immutable (i.e.,
> depending on the database's contents) checks during ALTER ROLE/DATABASET SET
> at all?
Yeah, I was wondering about that one too. It would not solve all the
problems here, but skipping validity checks w
On Oct20, 2011, at 00:09 , Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Oct 19, 2011 at 5:13 PM, Tom Lane wrote:
>>> I'm beginning to think that the correct solution to these problems is to
>>> greatly restrict what you can set in ALTER ROLE/DATABASE SET. Or at
>>> least to document that if
Robert Haas writes:
> On Wed, Oct 19, 2011 at 5:13 PM, Tom Lane wrote:
>> I'm beginning to think that the correct solution to these problems is to
>> greatly restrict what you can set in ALTER ROLE/DATABASE SET. Or at
>> least to document that if you use it, you get to keep both pieces after
>>
On Wed, Oct 19, 2011 at 5:13 PM, Tom Lane wrote:
> "David E. Wheeler" writes:
>> We've just found an issue with pg_dumpall in 9.1.1 where a dump starts with
>> lines like these:
>
>> ALTER ROLE dude WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB LOGIN
>> PASSWORD 'md5bdd7f8e73a214981b1519
On Oct 19, 2011, at 2:13 PM, Tom Lane wrote:
>>ALTER ROLE dude WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB LOGIN
>> PASSWORD 'md5bdd7f8e73a214981b1519212b02a5530' VALID UNTIL 'infinity';
>>ALTER ROLE dude SET default_tablespace TO 'users';
>
> I'm beginning to think that the correct
"David E. Wheeler" writes:
> We've just found an issue with pg_dumpall in 9.1.1 where a dump starts with
> lines like these:
> ALTER ROLE dude WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB LOGIN
> PASSWORD 'md5bdd7f8e73a214981b1519212b02a5530' VALID UNTIL 'infinity';
> ALTER ROLE dud
Hackers,
We've just found an issue with pg_dumpall in 9.1.1 where a dump starts with
lines like these:
ALTER ROLE dude WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB LOGIN
PASSWORD 'md5bdd7f8e73a214981b1519212b02a5530' VALID UNTIL 'infinity';
ALTER ROLE dude SET default_tablespace TO
13 matches
Mail list logo
