#9 reversed order of db notices

State changed from new to open

You are right, and using conn.notifies.pop(0) (or insert(0) when adding items) is inefficient. Probably we should use collections.deque and appendleft() on our side so that pop() on the client side would work as expected.

By the way there is a similar problem in conn.notices, which is a list whose max length is clipped to avoid unbounded growth (a problem we had with excessive warnings before we starting respecting the standard_conforming_strings setting).

The problem is as usual with backward compatibility as deque doesn't support all the list interface (e.g. slicing, don't know what else). I don't expect to break much code though, and the gain would be huge.

November 9th, 2010 @ 12:01 PM

Marko Kreen

Considering the notices are mostly debugging aid, I would not worry about efficiency too much.

But the reordering problem makes it hard to do even debugging, which is bad.

Note I was talking about this (temp) list:

struct connectionObject_notice *notice_pending;

not the Python array.

November 9th, 2010 @ 12:21 PM

Daniele Varrazzo

Uhm, I mixed notices and notifies: I think they both have the same efficiency problem.

The temporary notice_pending can definitely be fixed, thank you for the report. I agree the notices in this example should be made available in the opposite order in the notices list.

In [17]: cur.execute("select 'a\\a';\nselect 'b\\b'")

In [20]: print '\n'.join(cnn.notices)
WARNING:  nonstandard use of escape in a string literal
LINE 2: select 'b\b'
               ^
HINT:  Use the escape string syntax for escapes, e.g., E'\r\n'.

WARNING:  nonstandard use of escape in a string literal
LINE 1: select 'a\a';
               ^
HINT:  Use the escape string syntax for escapes, e.g., E'\r\n'.

November 9th, 2010 @ 12:39 PM

Daniele Varrazzo

State changed from open to resolved
Milestone set to release-2.3.0

Fixed in my branch, thank you.

November 11th, 2010 @ 11:56 AM

reversed order of db notices

Activity