Thread: [HACKERS] some dblink refactoring

[HACKERS] some dblink refactoring

From
Peter Eisentraut
Date:
Here is a patch to refactor some macro hell in dblink.

This patch was discussed in the background sessions thread as a
prerequisite for some work there, but I figure I'll make a separate
thread for it to give everyone interested in dblink a chance to respond
separate from the other thread.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Attachment

Re: [HACKERS] some dblink refactoring

From
Corey Huinker
Date:
On Tue, Feb 28, 2017 at 10:09 PM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
Here is a patch to refactor some macro hell in dblink.

This patch was discussed in the background sessions thread as a
prerequisite for some work there, but I figure I'll make a separate
thread for it to give everyone interested in dblink a chance to respond
separate from the other thread.

+1

Any chance we can make get_connect_string() a core function or at least externally accessible?

Re: [HACKERS] some dblink refactoring

From
Peter Eisentraut
Date:
On 2/28/17 22:22, Corey Huinker wrote:
> Any chance we can make get_connect_string() a core function or at least
> externally accessible?

[get_connect_string() gets the connection string for a foreign server]

The connection string for a foreign server depends on the nature of the
foreign server.  dblink can assume it's a PostgreSQL server, but it's
not clear how to generalize that.

Some kind of node or connection registry (i.e., "native" servers) might
be a better feature to think about here.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Re: [HACKERS] some dblink refactoring

From
"Tsunakawa, Takayuki"
Date:
From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Peter Eisentraut
> Here is a patch to refactor some macro hell in dblink.
> 
> This patch was discussed in the background sessions thread as a prerequisite
> for some work there, but I figure I'll make a separate thread for it to
> give everyone interested in dblink a chance to respond separate from the
> other thread.

I changed the status to ready for committer.  The patch applied cleanly, passed the regression test (make installcheck
incontrib/dblink/), and the code looks perfect.
 

How about applying the attached small patch for another refactoring?  This merely changes makeStringInfo() to
initStringInfo()at two sites just other places in the same file.  makeStringInfo() on the function local variables
leavesmemory for StringInfoData allocated unnecessarily (which may be automatically reclaimed some time after.)
 

Regards
Takayuki Tsunakawa




Re: [HACKERS] some dblink refactoring

From
"Tsunakawa, Takayuki"
Date:
From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Tsunakawa,
> Takayuki
> How about applying the attached small patch for another refactoring?  This
> merely changes makeStringInfo() to initStringInfo() at two sites just other
> places in the same file.  makeStringInfo() on the function local variables
> leaves memory for StringInfoData allocated unnecessarily (which may be
> automatically reclaimed some time after.)

Sorry, I forgot to attach the file.

Regards
Takayuki Tsunakawa



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Attachment

Re: [HACKERS] some dblink refactoring

From
Peter Eisentraut
Date:
On 3/8/17 00:10, Tsunakawa, Takayuki wrote:
> I changed the status to ready for committer.  The patch applied cleanly, passed the regression test (make
installcheckin contrib/dblink/), and the code looks perfect.
 
> 
> How about applying the attached small patch for another refactoring?  This merely changes makeStringInfo() to
initStringInfo()at two sites just other places in the same file.  makeStringInfo() on the function local variables
leavesmemory for StringInfoData allocated unnecessarily (which may be automatically reclaimed some time after.)
 

Committed both.  Thanks.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services