Skip site navigation (1) Skip section navigation (2)

Re: [GENERAL] dblink: rollback transaction

From: Joe Conway <mail(at)joeconway(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-patches(at)postgresql(dot)org,Oleg Lebedev <oleg(dot)lebedev(at)waterford(dot)org>
Subject: Re: [GENERAL] dblink: rollback transaction
Date: 2004-02-24 06:57:38
Message-ID: 403AF5E2.8040506@joeconway.com (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-patches
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?)

Joe


In response to

Responses

pgsql-patches by date

Next:From: Claudio NatoliDate: 2004-02-24 08:39:22
Subject: win32 int/float test fixes
Previous:From: Tom LaneDate: 2004-02-24 06:27:02
Subject: Re: [GENERAL] dblink: rollback transaction

pgsql-general by date

Next:From: Paul SimpsonDate: 2004-02-24 11:21:05
Subject: Why does app fail?
Previous:From: newsDate: 2004-02-24 06:54:25
Subject: Column headings using Comment?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group