Re: I am done

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: I am done
Date: 2002-09-02 16:21:04
Message-ID: 200209021621.g82GL4o20829@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Tom Lane wrote:
> >> This isn't really done; the backend side is probably okay, but we have
> >> a ton of client-side code that will malfunction if you try to run it in
> >> autocommit-off state.
>
> > My feeling is that we have to fix this during beta.
>
> No we don't.
>
> I don't think it *can* be fixed in a reasonable fashion until we have
> notification to the client side about what the backend's transaction
> state is; which is one of the protocol-change items for 7.4.

Why can't we just turn on auto-commit when we start the session:

SET autocommit = true;

> > Added to open items:
> > Fix client apps for autocommit = off
>
> Put it on TODO for 7.4, instead.
>
> BTW, why is there not a TODO item (or maybe a whole section) for all the
> protocol changes we want?

A few are mentioned in TODO, the others are mentioned in comments in the
code. I can gather them if you it would help.

> > Yep, marked, but right now there is no good way to turn off the printing
> > of queries on errors. We have to address that before 7.3 final.
>
> Oh, didn't you put in that patch to provide a GUC level control?

Yes, but what level do you set it at to turn it off? It goes from
DEBUG5 all the way up to ERROR but all of those print the query on an
error.

>
> > Can we dump/reload the regression database now?
>
> Yes.

Oh, OK, then removed.

> > Well, the lack of sequence for a SERIAL is an issue if only related to
> > the DEFAULT issue so I will keep it.
>
> I think you should merge the two items into one: the DEFAULT is the
> actual problem, but it'd be okay to note that it blocks adding a serial
> column.

OK, new text:

o ALTER TABLE ADD COLUMN column DEFAULT should fill existing
rows with DEFAULT value
o ALTER TABLE ADD COLUMN column SERIAL doesn't create sequence because
of the item above

> >> o Prevent DROP of table being referenced by our own open cursor
> >>
> >> Huh? There is no such bug that I know of.
>
> > Well, actually, there is or was.
>
> Oh, wait, our *own* open cursor. Okay --- I was testing it with a
> different backend trying to drop the table, and of course it blocked
> waiting to acquire exclusive lock on the table. But if it's our own
> cursor we won't block.

Don't know how I can improve that wording. :-)

> >> o -Disallow missing columns in INSERT ... VALUES, per ANSI
> >>
> >> What is this, and why is it marked done?
>
> > We used to allow INSERT INTO tab VALUES (...) to skip the trailing
> > columns and automatically fill in null's. That is fixed, per ANSI.
>
> Oh, I see: we compromised on being strict if you have an explicit list
> of column names. You can still omit trailing columns if you just
> say INSERT INTO foo VALUES(...), which is what the TODO item seems to
> say you can't do anymore.

Yes, that was a point not addressed in the TODO because that distinction
didn't exist at the time it was added. Text updated:

o -Disallow missing columns in INSERT ... (col) VALUES, per ANSI

> >> * Have SERIAL generate non-colliding sequence names when we have
> >> auto-destruction
> >>
> >> They should be pretty well non-colliding now. What's the gripe exactly?
>
> > The issue was that when there were name collisions, we threw an error
> > instead of trying other sequence names. We had to do that because we
> > needed the sequence name to be predictable so it could be auto-deleted.
> > Now with dependency, we don't need to have it be predictable.
>
> The system may not need that, but I think unpredictable sequence names
> are a bad idea from the user's point of view anyway. Also, the main
> reason why there was a problem before was the failure to auto-drop the
> sequence --- so you were certain to get a collision if you dropped and
> remade the table. So I think this is a non-problem now, and we should
> just remove the item.

OK, removed. Again, thank's for the review. I am working on HISTORY today.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gordon Runkle 2002-09-02 16:29:17 Re: [7.3-devl] converision test fails
Previous Message Bruce Momjian 2002-09-02 16:13:10 Re: current build fail