Re: Rationalizing code-sharing among src/bin/ directories

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Rationalizing code-sharing among src/bin/ directories
Date: 2016-03-25 00:52:21
Message-ID: 21707.1458867141@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
> On Fri, Mar 25, 2016 at 1:11 AM, Alvaro Herrera
> <alvherre(at)2ndquadrant(dot)com> wrote:
>> I wondered about the list stuff while messing about in pg_dump awhile
>> ago. It seems moderately okay, but not terribly generic; maybe we
>> should get rid of all that stuff and make ilist.c available to frontend.
>> Not sure how easy is that, given that AFAIR ilist uses elog. Anyway
>> maybe we can discuss that in the future, to avoid blocking your patch.

> Definitely worth it, list mimics of what is in pg_dump are located in
> pg_basebackup, and since a 9.6 patch in psql as well. That's as much
> code duplication.

Well, it's not a *lot* of code duplication. Agreed, it's a bit ugly
that we've got three or four copied-and-pasted versions of
simple_foo_list_append, but I'm not convinced that it'd be worth the
trouble to do anything about that. If FE code starts needing more list
functionality than that, maybe importing ilist or similar would be
worthwhile, but right now I think it would be overkill.

> Preventing the use of elog in the frontend is something that has been
> addressed multiple times with FRONTEND, so that's not likely going to
> be an issue I think. Andres has mentioned as well having some elog
> stuff available in frontend..

I'm on board with doing something about that one, though. There are
quite a lot of places that could be cleaned up.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2016-03-25 02:05:44 Re: Alter or rename enum value
Previous Message Michael Paquier 2016-03-25 00:28:18 Re: Proposal: "Causal reads" mode for load balancing reads without stale data