some dblink refactoring

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?

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

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

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 in 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 leaves memory for StringInfoData allocated unnecessarily (which may be automatically reclaimed some time after.)

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

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

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 installcheck in 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 leaves memory 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

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