Jim Nasby writes:
> On 3/1/16 5:06 PM, Tom Lane wrote:
>> If we don't do that, I'm at least going to put in a similar #error for
>> Tcl 8.0; but I really think we ought to just say 8.4 is the minimum.
> Just confirmed that should be completely reasonable. I'll take a look at
> it in a few days i
On 3/1/16 5:06 PM, Tom Lane wrote:
If we don't do that, I'm at least going to put in a similar #error for
Tcl 8.0; but I really think we ought to just say 8.4 is the minimum.
Just confirmed that should be completely reasonable. I'll take a look at
it in a few days if you don't beat me to it.
On 3/2/16 12:32 PM, Tom Lane wrote:
Jim Nasby writes:
[ pltcl_objects_2.patch ]
I've pushed this with some minor fixes, as well as the followup work
mentioned in this thread.
Awesome, thanks!
I've asked Karl's opinion on increasing the minimum TCL version, but I
suspect that won't be an i
Jim Nasby writes:
> [ pltcl_objects_2.patch ]
I've pushed this with some minor fixes, as well as the followup work
mentioned in this thread.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
ht
Victor Wagner writes:
> On Mon, 22 Feb 2016 17:57:36 -0600
> Jim Nasby wrote:
>> Is there any backwards compatibility risk to these changes? Could
>> having that new info break someone's existing code?
> I don't think so. ErrorCode and ErrorInfo mechanisms present in the Tcl
> for ages. As far a
On 2/29/16 9:57 AM, Tom Lane wrote:
plpgsql already has a similar mechanism (see PLpgSQL_function.use_count)
which you could probably copy. But I'd advise that this is a separate
matter to be addressed in a separate patch; it has little to do with the
nominal subject matter of this patch.
Ahh,
Jim Nasby writes:
> On 2/25/16 9:30 AM, Alvaro Herrera wrote:
>> Refcounting the prodesc would let it live until the cursor's closed,
>> then free it.
> I'm also not sure how the reference would get decremented... via
> ResourceOwner somehow?
plpgsql already has a similar mechanism (see PLpgSQL
On 2/25/16 9:30 AM, Alvaro Herrera wrote:
Jim Nasby wrote:
Here we have another case. prodesc is a global thing. And it is shared
between different operations. Problem was that there is no partcular
owner, and we have to wait when last operation which deals with it
would finish. It looks like p
Jim Nasby wrote:
> >Here we have another case. prodesc is a global thing. And it is shared
> >between different operations. Problem was that there is no partcular
> >owner, and we have to wait when last operation which deals with it
> >would finish. It looks like perfect job for reference counting
On Tue, 23 Feb 2016 17:14:26 -0600
Jim Nasby wrote:
> On 2/23/16 6:04 AM, Victor Wagner wrote:
>
> > Please, send updated patch to the list in this thread, so it would
> > appear in the commitfest and I can mark your patch as "ready for
> > committer".
>
> Done!
Nice job. I've marking the p
On 2/23/16 6:04 AM, Victor Wagner wrote:
On Mon, 22 Feb 2016 17:57:36 -0600
Jim Nasby wrote:
On 2/18/16 6:26 AM, Victor Wagner wrote:
(BTW, I also disagree about using a Tcl list for prodesc. That's an
object in a *Postgres* hash table; as such it needs to be managed by
Postgres, not Tcl. AFAI
On Mon, 22 Feb 2016 17:57:36 -0600
Jim Nasby wrote:
> On 2/18/16 6:26 AM, Victor Wagner wrote:
> Are you referring to this comment?
>
> > /
> > * Add the proc description block to the
> > hashtable. Note we do
On 2/18/16 6:26 AM, Victor Wagner wrote:
On Tue, 9 Feb 2016 16:23:21 -0600
There is suspicious place at the end of compile_pltcl_fuction function,
where you've put comment that old prodesc cannot be deallocated,
because it might be used by other call.
It seems that reference counting mechanism
On Tue, 9 Feb 2016 16:23:21 -0600
Jim Nasby wrote:
> Currently, pl/tcl is implemented through nothing but string
> manipulation. In other words, the C code is effectively creating a
> giant string that the tcl interpreter must re-parse every time the
> function is executed. Additionally, all arg
Currently, pl/tcl is implemented through nothing but string
manipulation. In other words, the C code is effectively creating a giant
string that the tcl interpreter must re-parse every time the function is
executed. Additionally, all arguments are treated as raw strings,
instead of the far more
15 matches
Mail list logo
