Activity (RSS)

Manually creating a thread and calling getcursor() from there returns a cursor on a connection that didn't receive the 'init' procedure (isolation level, encodi...

That's because you have put the RETURNING values into parenthesis, so postgres is returning a record value for which psycopg doesn't have a typecaster.

You have...

Submitted by: ChMeessen

When performing an SQL insert operation returning multiple values, which is valid, the value returned by fetchone()[0] is a string with ...

Fixed the problem: the exception now contains the PGresult. When the exception is created it takes ownership of the result, which is disposed of only when the e...

The connection is only used to get the encoding: we can store that too in the exception.

I'm getting crazy subtyping StandardError... enough for tonight.

Thanks. One possible complication I thought of is that the Diagnostics still wants to see a connection in order to call conn_text_from_chars(); I suppose that p...

Adding PQresult to the exception requires the Error exception to have a C structure (a PsycoErrorObject): I'm taking a look at doing it, using the Python System...

Oh well, that's true. Probably the idea of going diag->exception->cursor->PGresult is not so great after all.

Because typically after the exception the result i...

OK.

I think now that the problem is that, because commit is called directly on the connection, there is no cursor associated with the exception. So I'm not sure...

The test you are writing is not specific for PG 9.3: I'd drop the check for constraint_name, leave e.g. e.diag.sqlstate, which is present in all postgres versio...

Probably in pq_execute_command_locked, https://github.com/dvarrazzo/psycopg/blob/devel/psycopg/pqpath.c#L372

I think diagnostics aren't working for errors which are raised from COMMIT. I suppose the PQresult is being cleared too early, but I'm not sure where.

This test...

Fixed in devel, to be released soon.

Both patch works, I can see foomod went through without any problems.

Thanks!

What about this patch instead?

Maybe subclassing build_py is not necessary but it doesn't hurt.

diff --git a/setup.py b/setup.py
index 3791c14..96cd237 100644
...

Ignore the above patch: the problem is the list changed inplace

Can you test if this fix works?

diff --git a/setup.py b/setup.py
index 3791c14..bd0a8f3 100644
--- a/setup.py
+++ b/setup.py
@@ -55,10 +55,14 @@ from distutils...

Is there a different way to customize the list of fixers which wouldn't suffer of the shortcoming?

I hope to do some more work on it tomorrow. But of course I won't have any complaints if you fix things yourself.

Thank you very much, great work.

I've only included the five new 'enhanced error fields', but it should be easy enough 
to add properties for the other PG_DIAG...

Ok, I've pushed it to a 2013-03-17_diagnostics branch in mattheww/psycopg2 on github:
https://github.com/mattheww/psycopg2/tree/2013-03-17_diagnostics

It's base...

Great! Please push it on github.

I have something basically working now, using the design you described. If you like I'll publish what I've got so you can judge whether it looks suitable, and h...

The exception already contains a pointer to the cursor, hence it can reach the PQresult.

If we need to keep the PQresult upon error longer than we currently do ...

Fixed in devel branch

Pushed to devel, thank you.

♥

Correct patch now. I attached the wrong file in previous message (and deleted it now to avoid confusion).

Actually, I checked instead of just reasoning about it and I was wrong, the alternative also works.

The notices get counted only for tables that don't have prim...

I see, thank you for the tests. I'll commit your test suite patch for the next release.

They couldn't stay completely unchanged. With debug1 I get an extra message (building index...) so at least the test that counts the notices would need changes:

Some tests related to NOTICE messages fail with Posgres 9.3 (compiled from Git a few days ago).

The failures happen because statements like: create temp table c...

Last summer, when an earlier version of this Postgres patch was being considered, I had a look at adding support in Psycopg.

If you haven't started work on this...

I'd avoid a mapping as I don't want to query everything on object creation, only on attribute access.

That can also be done on mappings FWIW, but if it's goin...

Oh, I thought PQresultErrorField was a new api. This makes things easier.

I'd avoid a mapping as I don't want to query everything on object creation, only on at...

It's actually interesting. What I'd do is to add a diag attribute to the exception, that could be used to fetch the relevant attribute, something like:

That's...

It's actually interesting. What I'd do is to add a diag attribute to the exception, that could be used to fetch the relevant attribute, something like:

try:
  ...

Submitted by: masklinn

While not released yet, Postgres 9.3 (to be released in September 2013?) will apparently add a number of error fields useful for programm...

Thank you for the report and the analysis: we'll look into that.

Submitted by: reno.gan@gmail.com

In our environment, every client connection has a max idle time. If this time expires, pg server will disconnect its connection...