Re: [GENERAL] dblink: rollback transaction

From: Joe Conway <mail(at)joeconway(dot)com>
To: pgsql-patches(at)postgresql(dot)org
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Oleg Lebedev <oleg(dot)lebedev(at)waterford(dot)org>
Subject: Re: [GENERAL] dblink: rollback transaction
Date: 2004-03-05 06:11:56
Message-ID: 40481A2C.1010806@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-patches

Joe Conway wrote:
> Tom Lane wrote:
>> Joe Conway <mail(at)joeconway(dot)com> writes:
>>> I like the idea in general, but maybe instead there should be a new
>>> overloaded version of the existing function names that accepts an
>>> additional bool argument. Without the argument, behavior would be as
>>> it is now; with it, you could specify the old or new behavior.
>>
>> Um, maybe I'm confused about the context, but aren't we talking about C
>> function names here? No overloading is possible in C ...
>
> I was thinking in terms of overloaded SQL function names. For example,
> in addition to dblink_exec(text) and dblink_exec(text,text) we create
> dblink_exec(text,bool) and dblink_exec(text,text,bool).
>
> Currently both SQL versions of dblink_exec are implemented by a single C
> level function. But yes, we'd need another C level function to support
> the new SQL functions because there would be no way to distinguish the 2
> two-argument versions otherwise. (Actually, now I'm wondering if we
> could use a single C function for all four SQL versions -- between
> PG_NARGS() and get_fn_expr_argtype() we should be able to figure out how
> we were called, shouldn't we?)

The attached implements the new overloaded SQL functions as discussed
above (i.e. start with existing argument combinations, add a new bool
argument to each). I ended up with a single C function (by making use of
number and type of the arguments) for each overloaded SQL function name.

I'll commit in a day or two if there are no objections.

Thanks,

Joe

Attachment Content-Type Size
dblink-fail.3.patch text/plain 42.9 KB

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Mike Mascari 2004-03-05 09:04:37 Re: Moving from MySQL to PGSQL....some questions (multilevel
Previous Message Joseph Shraibman 2004-03-05 05:47:11 performance problems: join conditions

Browse pgsql-patches by date

  From Date Subject
Next Message Michael Glaesemann 2004-03-05 08:01:11 Re: notice about costly ri checks (2)
Previous Message Tom Lane 2004-03-05 05:04:31 Re: pg_autovacuum patch for 7.4.2 and HEAD