On 2019-11-06 15:49, Tom Lane wrote:
Peter Eisentraut writes:
On 2019-11-04 16:01, Tom Lane wrote:
Now that I've actually looked at the patched code, there's a far
more severe problem with it. Namely, that use of PG_FINALLY
means that the "finally" segment is run without having popped
the err
Peter Eisentraut writes:
> On 2019-11-04 16:01, Tom Lane wrote:
>> Now that I've actually looked at the patched code, there's a far
>> more severe problem with it. Namely, that use of PG_FINALLY
>> means that the "finally" segment is run without having popped
>> the error context stack, which mea
On 2019-11-04 16:01, Tom Lane wrote:
Now that I've actually looked at the patched code, there's a far
more severe problem with it. Namely, that use of PG_FINALLY
means that the "finally" segment is run without having popped
the error context stack, which means that any error thrown
within that s
Peter Eisentraut writes:
> On 2019-11-02 15:36, Tom Lane wrote:
>> I hadn't actually tested this patch before commit, but now that
>> it's in, I'm seeing assorted compiler warnings:
> I've fixed the ones that I could reproduce on CentOS 6. I haven't seen
> any on a variety of newer systems.
I'
On 2019-11-02 15:36, Tom Lane wrote:
I hadn't actually tested this patch before commit, but now that
it's in, I'm seeing assorted compiler warnings:
I've fixed the ones that I could reproduce on CentOS 6. I haven't seen
any on a variety of newer systems.
It's not clear why only a handful of
Peter Eisentraut writes:
> committed with a leading underscore
I hadn't actually tested this patch before commit, but now that
it's in, I'm seeing assorted compiler warnings:
plpy_exec.c: In function 'PLy_procedure_call':
plpy_exec.c:1028: warning: 'rv' may be used uninitialized in this function
On 2019-10-29 17:10, Tom Lane wrote:
Peter Eisentraut writes:
On 2019-10-28 13:45, Robert Haas wrote:
In theory, the do_rethrow variable could conflict with a symbol
declared in the surrounding scope, but that doesn't seem like it's a
problem worth getting worked up about.
Right. A PG_TRY
Peter Eisentraut writes:
> On 2019-10-28 13:45, Robert Haas wrote:
>> In theory, the do_rethrow variable could conflict with a symbol
>> declared in the surrounding scope, but that doesn't seem like it's a
>> problem worth getting worked up about.
> Right. A PG_TRY block also declares other loca
On 2019-10-28 13:45, Robert Haas wrote:
In theory, the do_rethrow variable could conflict with a symbol
declared in the surrounding scope, but that doesn't seem like it's a
problem worth getting worked up about.
Right. A PG_TRY block also declares other local variables for internal
use withou
On Mon, Oct 28, 2019 at 4:43 AM Peter Eisentraut
wrote:
> Here is a new implementation that works just like that.
This looks like a marked notational improvement.
With the patch:
[rhaas pgsql]$ git grep PG_CATCH | wc -l
102
[rhaas pgsql]$ git grep PG_FINALLY | wc -l
55
I'm actually
On 2018-12-14 16:49, Tom Lane wrote:
I don't especially like the MACRO({...}) proposal, because it looks way
too much like gcc's special syntax for "statement expressions". If we
have to go this way, I'd rather see if MACRO((...)) can be made to work.
But I question your assumption that we have
Peter Eisentraut writes:
> The fundamental problem, as I see it, is that the macro expansion needs
> to produce the "finally" code twice: Once in the else (error) branch of
> the setjmp, and once in the non-error code path, either after the
> if-setjmp, or in the try block. But to be able to do t
On 13/12/2018 13:26, Kyotaro HORIGUCHI wrote:
> Though I didn't look into individual change, this kind of
> refactoring looks good to me. But the syntax looks
> somewhat.. uh..
>
> I'm not sure it is actually workable, but I suspect that what we
> need here is just a shortcut of 'PG_CATCH();{PG_RE
Andrew Dunstan writes:
> But the block inside parentheses feels kinda funny, doesn't it?
+1. I think this is a good concept, but let's put in enough effort to
not require weird syntax.
regards, tom lane
On 12/13/18 7:26 AM, Kyotaro HORIGUCHI wrote:
> At Thu, 13 Dec 2018 11:33:39 +0100, Peter Eisentraut
> wrote in
>
>>
>> I've played with a way to express this more compactly:
>>
>> PG_TRY();
>> {
>> ... code that might throw ereport(ERROR) ...
>> }
>> PG_FINALLY({
>>
On 12/13/18 5:33 AM, Peter Eisentraut wrote:
> This is a common pattern:
>
> PG_TRY();
> {
> ... code that might throw ereport(ERROR) ...
> }
> PG_CATCH();
> {
> cleanup();
> PG_RE_THROW();
> }
> PG_END_TRY();
> cleanup(); /* the same as ab
At Thu, 13 Dec 2018 11:33:39 +0100, Peter Eisentraut
wrote in
> This is a common pattern:
>
> PG_TRY();
> {
> ... code that might throw ereport(ERROR) ...
> }
> PG_CATCH();
> {
> cleanup();
> PG_RE_THROW();
> }
> PG_END_TRY();
> cleanup()
17 matches
Mail list logo
