Обсуждение: Heading to final release
We only have a few open items left. Let's make final decisions on these
and schedule RC1.
---------------------------------------------------------------------------
P O S T G R E S Q L
7 . 4 O P E N I T E M S
Current at ftp://momjian.postgresql.org/pub/postgresql/open_items.
Changes
-------
Allow superuser (dba?) the ability to turn off foreign key checks/all constraints/triggers, not settable from
postgresql.conf?
Move ANALYZE before foreign key creation?
Rename dump GUC variable to be more generic
What to do about exposing the list of possible SQLSTATE error codes
Documentation Changes
---------------------
Move release notes to SGML
Freeze message strings
-- 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,
Pennsylvania19073
> Changes > ------- > Allow superuser (dba?) the ability to turn off foreign key checks/all > constraints/triggers, not settable from postgresql.conf? Is that one really necessary for 7.4 now that adding foreign keys is apparently much faster? Chris
Christopher Kings-Lynne wrote: > > > Changes > > ------- > > Allow superuser (dba?) the ability to turn off foreign key checks/all > > constraints/triggers, not settable from postgresql.conf? > > Is that one really necessary for 7.4 now that adding foreign keys is > apparently much faster? That's why it has a question mark --- we have to decide. -- 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, Pennsylvania19073
Bruce Momjian wrote: > Christopher Kings-Lynne wrote: >> >> > Changes >> > ------- >> > Allow superuser (dba?) the ability to turn off foreign key checks/all >> > constraints/triggers, not settable from postgresql.conf? >> >> Is that one really necessary for 7.4 now that adding foreign keys is >> apparently much faster? > > That's why it has a question mark --- we have to decide. > I am still for it. If you reconfigure your systems to force fsck on every boot, cleanly unmounted or not, you can vote against. Otherwise you are basically for this option. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
> >> > Allow superuser (dba?) the ability to turn off foreign key checks/all > >> > constraints/triggers, not settable from postgresql.conf? > >> > >> Is that one really necessary for 7.4 now that adding foreign keys is > >> apparently much faster? > If you reconfigure your systems to force fsck on every boot, cleanly > unmounted or not, you can vote against. Otherwise you are basically for > this option. I vote to disable the checks for pg_restore if the dumpfile has a check added to ensure it's the same file that was dumped (an MD5 in the header) and it is a full database restore. Individual table restores should require the check.
Rod Taylor <rbt@rbt.ca> writes:
> I vote to disable the checks for pg_restore if the dumpfile has a check
> added to ensure it's the same file that was dumped (an MD5 in the
> header) and it is a full database restore.
> Individual table restores should require the check.
It is not our business to be making such decisions for the DBA. If
we're going to provide this at all, it should be in the form of a knob
the DBA can tweak if *he* thinks it's safe to omit the check.
regards, tom lane
Tom Lane wrote: > Rod Taylor <rbt@rbt.ca> writes: > > I vote to disable the checks for pg_restore if the dumpfile has a check > > added to ensure it's the same file that was dumped (an MD5 in the > > header) and it is a full database restore. > > Individual table restores should require the check. > > It is not our business to be making such decisions for the DBA. If > we're going to provide this at all, it should be in the form of a knob > the DBA can tweak if *he* thinks it's safe to omit the check. We could allow the dba to _enable_ the check if they want it, of course. Basically, default it to checks off rather than on. However, there is no logic that could distinguish a hand-created dump from one we dumped. This is another area where a guc variable identifing a dump would help. -- 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, Pennsylvania19073
Rod Taylor wrote:
>> >> > Allow superuser (dba?) the ability to turn off foreign key checks/all
>> >> > constraints/triggers, not settable from postgresql.conf?
>> >>
>> >> Is that one really necessary for 7.4 now that adding foreign keys is
>> >> apparently much faster?
>
>> If you reconfigure your systems to force fsck on every boot, cleanly
>> unmounted or not, you can vote against. Otherwise you are basically for
>> this option.
>
> I vote to disable the checks for pg_restore if the dumpfile has a check
> added to ensure it's the same file that was dumped (an MD5 in the
> header) and it is a full database restore.
>
> Individual table restores should require the check.
I don't like it.
Rod, this is not meant personal, more some sort of general sigh:
Why do people wait until the EMT cannot give the life-saving infusion
any more before they realize that "invincible" isn't that great at all?
Some dumb-user/fat-finger/ooops protection is surely welcome, but there
is a limit. A system console has to be behind a locked door instead of
the single-user boot being root-password protected. As soon as people
succeed in "chmod 0000 /" and it honor's that for root even if the disk
is mounted on a different system, they will see that there is something
missing - ooops, too late?
I am talking about some special super-user flag. Something that is
available for the user who has usecatupd anyway and because of that he
can do a
DELETE FROM pg_class WHERE relname = 'pg_class';
What good is it to deny "that" user to import any dump without foreign
key check? Any attempt to do so only makes it "more inconvenient". But
you surely don't prevent anything by doing so.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
On Mon, 2003-10-13 at 21:26, Jan Wieck wrote: > Rod Taylor wrote: > >> >> > Allow superuser (dba?) the ability to turn off foreign key checks/all > >> >> > constraints/triggers, not settable from postgresql.conf? > >> >> > >> >> Is that one really necessary for 7.4 now that adding foreign keys is > >> >> apparently much faster? > > > >> If you reconfigure your systems to force fsck on every boot, cleanly > >> unmounted or not, you can vote against. Otherwise you are basically for > >> this option. > > > > I vote to disable the checks for pg_restore if the dumpfile has a check > > added to ensure it's the same file that was dumped (an MD5 in the > > header) and it is a full database restore. > > > > Individual table restores should require the check. > > I don't like it. > > Rod, this is not meant personal, more some sort of general sigh: > > Why do people wait until the EMT cannot give the life-saving infusion > any more before they realize that "invincible" isn't that great at all? > > Some dumb-user/fat-finger/ooops protection is surely welcome, but there > is a limit. A system console has to be behind a locked door instead of > the single-user boot being root-password protected. As soon as people Unfortunately, as more and more companies start to outsource their server administration these are the people who will be interacting with the database more in this role -- in fact, for most it is the only time they'll ever be on the database box. What I would like to see is to make these items permission based. For example, a permission that allows creation a new database and ownership changes (away from self) but nothing else. This would be adequate for 'safe-only' restores.
Rod Taylor wrote: > On Mon, 2003-10-13 at 21:26, Jan Wieck wrote: >> Why do people wait until the EMT cannot give the life-saving infusion >> any more before they realize that "invincible" isn't that great at all? >> >> Some dumb-user/fat-finger/ooops protection is surely welcome, but there >> is a limit. A system console has to be behind a locked door instead of >> the single-user boot being root-password protected. As soon as people > > Unfortunately, as more and more companies start to outsource their > server administration these are the people who will be interacting with > the database more in this role -- in fact, for most it is the only time > they'll ever be on the database box. Sure. But did adding gazillions of "Are you sure?" buttons help the slightest little bit in preventing idiots from voluntarily installing Viruses, worms, spam-gateways and other shit on their computers? I *love* these safety mechanisms ... they are totally annoying for anyone who knows what he's doing, and the dumbasses they intend to protect click blindly around without reading the messages just to get rid of the unexpected popup. You can build more secure systems as long as you want, evolution will develop the better idiot. As long as you create safer cars with more airbags, people will drive faster and more risky. When you start to replace all these stupid airbags with foot-long daggers that pop out of the steeringwheel on impact and instantly "kill" the driver, natural selection will kick in, increase traffic safety and lower the number of deaths in car accidents. You might notice a little peak in the statistics, or you might be part of the peak ... it's your choice. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
> >> Some dumb-user/fat-finger/ooops protection is surely welcome, but there > >> is a limit. A system console has to be behind a locked door instead of > >> the single-user boot being root-password protected. As soon as people > > > > Unfortunately, as more and more companies start to outsource their > > server administration these are the people who will be interacting with > > the database more in this role -- in fact, for most it is the only time > > they'll ever be on the database box. > You can build more secure systems as long as you want, evolution will > develop the better idiot. As long as you create safer cars with more Consider it like shipping. You can assume that UPS, FedEx or whomever will be nice and gentle to the package marked 'Fragile' and has a 'This Side Up' sticker OR you can double box it and use plenty of tightly packed peanuts. One of those 2 options is bound to have busted up contents by the time it reaches the other side nearly every time -- but they could still run a fork lift through the thing. Yes, if you're going to drive the package to the destination yourself, then all of the extra packaging would just get in the way -- but shipping has been outsourced by your company to save funds. If the product breaks when it gets to the client, it isn't going to be the shipping companies fault. It's the same reason PostgreSQL will not load when the blocksize has changed and why RESTRICT / CASCADE options exist for inter-object enforcement. Anyway, add the option if you like BUT can we start protecting these things with something more than superuser access? You require superuser to do daily maintenance tasks with PostgreSQL but for the most part these are exactly the wrong people to be making decisions about whether it is safe to do action X or Y at the time. Anyway, one of the local Nuclear power plants has safety courses. At the safest plant in Canada the operators have an accuracy rate of close to 99.9%. That is, they make the correct choice or complete the correct action for 99.9% of the choices in their day. This means at that plant there are 50 potentially fatal decision made every month. I simply want to remove the junior electricians ability to pick the wrong panel at the datacentre by ensuring someone else has given them the key. I want to remove my 'super users' ability to make a bad decision (even though they're 99.9% accurate in their decision making) by granting or revoking their ability to do so.
On Mon, Oct 13, 2003 at 11:51:52PM -0400, Jan Wieck wrote: > You can build more secure systems as long as you want, evolution will > develop the better idiot. As long as you create safer cars with more Sure, but I think all Rod is asking for is something like the ability to add the -w switch to perl in order to see things that he might have overlooked. I can't see any principled objection to that, especially if, as Bruce suggested, it defaults to off. (Of course, if the switch isn't ready, I dunno whether it's worth waiting for. Sounds like a feature to me.) A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada <andrew@libertyrms.info> M2P 2A8 +1 416 646 3304 x110
Bruce Momjian writes: > What to do about exposing the list of possible SQLSTATE error codes I say we put the list in the documentatio and that's it. Exposing the list in C header files wouldn't really be an ultimate solution, because not everyone uses C. > Freeze message strings That is old news. -- Peter Eisentraut peter_e@gmx.net
I wonder if this is feasible to enhance create trigger so I could say 'create or replace' Thanks, Mike.