what about my Privilege regression failure?
I'm not sure why it's dying...
LER
--On Monday, October 27, 2003 23:32:45 -0500 Tom Lane <tgl@sss.pgh.pa.us>
wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> We only have a few open items left. Can we finish them so we can move
>> toward final release?
>
> Okay, here's my two cents:
>
>> Allow superuser (dba?) the ability to turn off foreign key checks/all
>> constraints/triggers, not settable from postgresql.conf?
>
> We have seen a wide variety of proposals and opinions on this, ranging
> from "you can turn off the C in ACID anytime you want" to "you can
> suppress ALTER TABLE ADD FOREIGN KEY's cross-check ... and nothing else
> ... but only if you are superuser, mutter the right secret password, and
> spin three times widdershins". I am in the "three times widdershins"
> camp myself. But given the lack of consensus, I think the right
> short-term answer is to do nothing further. We can improve this more
> in future releases.
>
>> Move ANALYZE before foreign key creation?
>
> "Move"? pg_dump scripts don't issue ANALYZE at all. Again, I think
> this is not something to be introducing at the last minute.
>
>> Rename dump GUC variable to be more generic
>
> Sure, if we can agree on a name.
>
>> Document new --describe-config postgres option
>
> Go to it.
>
>> Have gcc use -g, add --disable-debug, rename?
>
> Personally I don't like the idea of this behavior defaulting differently
> depending on which compiler you use. I can see the practical arguments
> for doing so, but it still rubs me the wrong way. Can anyone offer new
> arguments pro or con here?
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749