Bruce Momjian <[EMAIL PROTECTED]> 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.
> 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?
> 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?
> Can we dump/reload the regression database now?
Yes.
> 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.
>> 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.
>> 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.
>> * 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.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
