From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Access to dynamic SQL in PL/pgSQL |
Date: | 2010-01-22 16:33:37 |
Message-ID: | 2208.1264178017@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> Anyway, there already was another way of doing this, so it shall be done
> that way instead. The beauty of a pluggable architecture is that one
> does not need approval to implement customer solutions.
If you're talking about a bundle that you're shipping to customers,
of course you can do whatever you want, since you can ensure that
your plpgsql.so and your plugin are compatible. Stuff we release
into the wide world doesn't have that luxury. We can't assume much
more than what PG_MODULE_MAGIC will enforce for us, and that means
ABI breaks within a major release series are dangerous.
But to get back to the point, what have you got against adding
another plugin call within the statements that build dynamic
queries? It seems like a much cleaner solution to me, and not
any different from the standpoint of back-portability.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-01-22 16:40:19 | pgsql: Replace ALTER TABLE ... |
Previous Message | Robert Haas | 2010-01-22 16:29:14 | Re: commit fests (was Re: primary key error message) |