On Thu, Feb 23, 2012 at 8:35 PM, Daniele Varrazzo
daniele.varra...@gmail.com wrote:
On Mon, Feb 20, 2012 at 12:09 AM, Jan Urbański wulc...@wulczer.org wrote:
BTW, that tool is quite handy, I'll have to try running it over psycopg2.
Indeed. I'm having a play with it. It is reporting several
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= wulc...@wulczer.org writes:
Here are the updated patches which use PLy_elog instead of plain elog.
The difference is that they will get marked for translation and that the
original Python exception will show up in the errdetail field.
Applied, thanks.
On Mon, Feb 20, 2012 at 12:09 AM, Jan Urbański wulc...@wulczer.org wrote:
BTW, that tool is quite handy, I'll have to try running it over psycopg2.
Indeed. I'm having a play with it. It is reporting several issues to
clean up (mostly on failure at module import). It's also tracebacking
here and
On 21/02/12 18:28, Jan Urbański wrote:
On 21/02/12 18:05, Peter Eisentraut wrote:
it might be better to use ereport, to expose the message
for translation.
After giving it some thought some of these elogs could be changed into
PLy_elogs (which is meant to propagate a Python error into
On sön, 2012-02-19 at 22:29 -0500, Tom Lane wrote:
My only comment is whether elog(ERROR) is appropriate, ie, do we
consider these to be internal errors that users will never see in
practice? If there's a significant risk of the error being thrown in
the field, it might be better to use
On 21/02/12 18:05, Peter Eisentraut wrote:
On sön, 2012-02-19 at 22:29 -0500, Tom Lane wrote:
My only comment is whether elog(ERROR) is appropriate, ie, do we
consider these to be internal errors that users will never see in
practice? If there's a significant risk of the error being thrown in
On 20/02/12 04:29, Tom Lane wrote:
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= wulc...@wulczer.org writes:
On 18/02/12 21:17, Tom Lane wrote:
Dave Malcolm at Red Hat has been working on a static code analysis tool
for Python-related C code. He reports here on some preliminary results
for plpython.c:
On Mon, Feb 20, 2012 at 5:05 AM, Jan Urbański wulc...@wulczer.org wrote:
On 20/02/12 04:29, Tom Lane wrote:
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= wulc...@wulczer.org writes:
On 18/02/12 21:17, Tom Lane wrote:
Dave Malcolm at Red Hat has been working on a static code analysis tool
for
On 18/02/12 21:18, Jan Urbański wrote:
On 18/02/12 21:17, Tom Lane wrote:
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= wulc...@wulczer.org writes:
On 18/02/12 20:30, Tom Lane wrote:
Dave Malcolm at Red Hat has been working on a static code analysis tool
for Python-related C code. He reports here on some
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= wulc...@wulczer.org writes:
On 18/02/12 21:17, Tom Lane wrote:
Dave Malcolm at Red Hat has been working on a static code analysis tool
for Python-related C code. He reports here on some preliminary results
for plpython.c:
On 18/02/12 20:30, Tom Lane wrote:
Dave Malcolm at Red Hat has been working on a static code analysis tool
for Python-related C code. He reports here on some preliminary results
for plpython.c:
https://bugzilla.redhat.com/show_bug.cgi?id=795011
I'm not enough of a Python hacker to evaluate
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= wulc...@wulczer.org writes:
On 18/02/12 20:30, Tom Lane wrote:
Dave Malcolm at Red Hat has been working on a static code analysis tool
for Python-related C code. He reports here on some preliminary results
for plpython.c:
On 18/02/12 21:17, Tom Lane wrote:
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= wulc...@wulczer.org writes:
On 18/02/12 20:30, Tom Lane wrote:
Dave Malcolm at Red Hat has been working on a static code analysis tool
for Python-related C code. He reports here on some preliminary results
for plpython.c:
13 matches
Mail list logo
