On Thu, Feb 23, 2012 at 8:35 PM, Daniele Varrazzo
wrote:
> On Mon, Feb 20, 2012 at 12:09 AM, Jan Urbański 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
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= 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.
r
On Mon, Feb 20, 2012 at 12:09 AM, Jan Urbański 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 there: I'll send t
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
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 thro
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 ere
On Mon, Feb 20, 2012 at 5:05 AM, Jan Urbański wrote:
> On 20/02/12 04:29, Tom Lane wrote:
>> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= 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
On 20/02/12 04:29, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= 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:
h
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= 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:
>>> https://bugzilla.redhat.com/show_bug.cgi?id
On 18/02/12 21:18, Jan Urbański wrote:
> On 18/02/12 21:17, Tom Lane wrote:
>> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= 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 preli
On 18/02/12 21:17, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= 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:
>>> https:
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= 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:
>> https://bugzilla.redhat.com/show_bug.cgi?id=7950
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 eva
13 matches
Mail list logo
