Just use plproxy and skip all the hassle of dblink :)
On Mon, Jun 2, 2008 at 3:14 AM, Joe Conway <mail(at)joeconway(dot)com> wrote:
> Tom Lane wrote:
>> Tommy Gildseth <tommy(dot)gildseth(at)usit(dot)uio(dot)no> writes:
>>> One obvious disadvantage of this approach, is that I need to connect and
>>> disconnect in every function. A possible solution to this, would be having a
>>> function f.ex dblink_exists('connection_name') that returns true/false
>>> depending on whether the connection already exists.
>> Can't you do this already?
>> SELECT 'myconn' = ANY (dblink_get_connections());
>> A dedicated function might be a tad faster, but it probably isn't going
>> to matter compared to the overhead of sending a remote query.
> I agree. The above is about as simple as
> SELECT dblink_exists('dtest1');
> and probably not measurably slower. If you still think a dedicated function
> is needed, please send the output of some performance testing to justify it.
> If you really want the notational simplicity, you could use an SQL function
> to wrap it:
> CREATE OR REPLACE FUNCTION dblink_exists(text)
> RETURNS bool AS $$
> SELECT $1 = ANY (dblink_get_connections())
> $$ LANGUAGE sql;
> contrib_regression=# SELECT dblink_exists('dtest1');
> (1 row)
> I guess it might be worthwhile adding the SQL function definition to
> dblink.sql.in as an enhancement in 8.4.
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
In response to
pgsql-hackers by date
|Next:||From: Dave Page||Date: 2008-06-02 07:37:36|
|Subject: Re: Overhauling GUCS|
|Previous:||From: Robert Hodges||Date: 2008-06-02 06:51:29|
|Subject: Re: Table rewrites vs. pending AFTER triggers|