Thread: [HACKERS] some dblink refactoring
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
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
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
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
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