Re: proposal: persistent plpgsql plugin info - field plugin_info for plpgsql_function structure

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: persistent plpgsql plugin info - field plugin_info for plpgsql_function structure
Date: 2013-12-31 20:44:35
Message-ID: 31564.1388522675@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> Requested feature doesn't help me implement this concept 100%, but helps
> with check If I worked with some instance of function or not. And inside
> core a implementation is cheap. Outside core it is a magic with hash and
> checking transaction id (about 200 lines). When I worked on extension for
> coverage calculation I had to solve same task, so I think so this variable
> can be useful generally for similar tasks.

Are you proposing a reserved-for-plugins "void*" in struct
PLpgSQL_function similar to the existing one in struct PLpgSQL_execstate?

If so, while it sounds harmless in itself, I think your argument above is
actually the strongest reason *not* to do it. The existing plpgsql plugin
infrastructure is incapable of supporting more than one plugin at a time,
and the more attractive we make it, the more likely we're going to have
conflicts. It was never meant to support anything but the plpgsql
debugger. Before we start aiding and abetting the development of other
plugins, we need a design that allows more than one of them to be
installed.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Adrian Klaver 2013-12-31 20:57:20 Re: pg_upgrade & tablespaces
Previous Message Alvaro Herrera 2013-12-31 20:32:16 Re: proposal: multiple read-write masters in a cluster with wal-streaming synchronization