Re: I propose killing PL/Tcl's "modules" infrastructure

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

In response to

Responses

Browse pgsql-hackers by date

  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