From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
Cc: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org, Jan Wieck <jan(at)wi3ck(dot)info> |
Subject: | Re: I propose killing PL/Tcl's "modules" infrastructure |
Date: | 2017-03-02 17:59:58 |
Message-ID: | 17748.1488477598@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> writes:
> On 2/27/17 2:42 PM, Tom Lane wrote:
>> + SET pltcl.start_proc = 'no_such_function';
>> + select tcl_int4add(1, 2);
>> + ERROR: function no_such_function() does not exist
> Can the error message be more explicit somehow? Otherwise people will be
> quite confused as to where no_such_function() is coming from.
After thinking about that for awhile, it seemed like the most useful thing
to do is to set up an errcontext callback that will be active throughout
execution of the start_proc. That will cover both setup failures like
the above, and errors occurring within the start_proc, which could be
equally confusing if you think they apply to the function you initially
tried to call. v2 patch attached that does it like that.
> <begin creature-feep>
> BTW, I'd think this functionality would be valuable for every PL.
Maybe for some. I see no value in putting anything about it in
pg_language though. I don't see that we could share any useful amount of
mechanism, and it won't necessarily look the same in every language ---
plperl for instance prefers code fragments over procedures.
In any case, I'm not going there in this patch.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
pltcl_start_proc-2.patch | text/x-diff | 17.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2017-03-02 18:32:05 | Re: patch: function xmltable |
Previous Message | Pavel Stehule | 2017-03-02 17:46:23 | Re: patch: function xmltable |