
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, Pennsylvania 19073

Sun, 12 Oct 2003 19:07:17 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Heading to final release

> 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



Mon, 13 Oct 2003 09:54:49 +0800
Christopher Kings-Lynne <chriskl@familyhealth.com.au>
Re: Heading to final release
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, Pennsylvania 19073

Sun, 12 Oct 2003 23:01:44 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Heading to final release
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 #


Mon, 13 Oct 2003 15:21:07 -0400
Jan Wieck <JanWieck@Yahoo.com>
Re: Heading to final release
> >> > 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.
Mon, 13 Oct 2003 20:07:05 -0400
Rod Taylor <rbt@rbt.ca>
Re: Heading to final release
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

Mon, 13 Oct 2003 20:27:01 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Heading to final release 
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, Pennsylvania 19073

Mon, 13 Oct 2003 20:34:04 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Heading to final release
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 #


Mon, 13 Oct 2003 21:26:38 -0400
Jan Wieck <JanWieck@Yahoo.com>
Re: Heading to final release
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.
Mon, 13 Oct 2003 22:13:59 -0400
Rod Taylor <rbt@rbt.ca>
Re: Heading to final release
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 #


Mon, 13 Oct 2003 23:51:52 -0400
Jan Wieck <JanWieck@Yahoo.com>
Re: Heading to final release
> >> 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.
Tue, 14 Oct 2003 08:53:11 -0400
Rod Taylor <rbt@rbt.ca>
Re: Heading to final release
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


Tue, 14 Oct 2003 09:56:49 -0400
Andrew Sullivan <andrew@libertyrms.info>
Re: Heading to final release
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


Tue, 14 Oct 2003 17:17:40 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: Heading to final release
I wonder if this is feasible to enhance create trigger
so I could say 'create or replace'

Thanks,
Mike.



Tue, 14 Oct 2003 12:01:47 -0400
Michael Brusser <michael@synchronicity.com>
feature request