Re: pg_dump refactor patch to remove global variables

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: pg_dump refactor patch to remove global variables
Дата
Msg-id 20141008184757.GW7043@eldon.alvh.no-ip.org
обсуждение исходный текст
Ответ на Re: pg_dump refactor patch to remove global variables  (Joachim Wieland <joe@mcknight.de>)
Ответы Re: pg_dump refactor patch to remove global variables
Список pgsql-hackers
Joachim Wieland wrote:
> On Sat, Aug 30, 2014 at 11:12 PM, Peter Eisentraut <peter_e@gmx.net> wrote:

> > - The forward declaration of struct _dumpOptions in pg_backup.h seems
> > kind of useless.  You could move some things around so that that's not
> > necessary.
>
> Agreed, fixed.
>
> > - NewDumpOptions() and NewRestoreOptions() are both in
> > pg_backup_archiver.c, but NewRestoreOptions() is in pg_backup.h whereas
> > NewDumpOptions() is being put into pg_backup_archiver.h.  None of that
> > makes too much sense, but it could be made more consistent.
>
> I would have created the prototype in the respective header of the .c
> file that holds the function definition, but that's a bit fuzzy around
> pg_dump. I have now moved the DumpOptions over to pg_backup.h, because
> pg_backup_archiver.h includes pg_backup.h so that makes pg_backup.h
> the lower header.

I gave this a look and my conclusion is that the current situation
doesn't make much sense -- supposedly, pg_backup.h is the public header
and pg_dump.h is the private header; then how does it make sense that
the former includes the latter?  I think the reason is that the struct
definitions are not well placed.  In the attached patch, which applies
on top of the rebase of Joachim's patch I submitted yesterday, I fix
that by moving some structs (those that make sense for the public
interface) to a new file, pg_dump_structs.h (better naming suggestions
welcome).  This is included everywhere as needed; it's included by
pg_backup.h, in particular.

With the new header in place I was able to remove most of cross-header
forward struct declarations that were liberally used to work around what
would otherwise be circularity in header dependencies.  I think it makes
much more sense this way.

With this, headers are cleaner and they compile standalone.  pg_backup.h
does not include pg_dump.h anymore.  DumpId and CatalogId, which were
kinda public but defined in the private header (!?), were moved to
pg_backup.h.  This is necessary because the public functions use them.

The one header not real clear to me is pg_backup_db.h.  Right now it
includes pg_backup_archiver.h, because some of its routines take an
ArchiveHandle argument, but that seems pretty strange if looking at it
from 10,000 miles.  I think we could fix this by having the routines
take Archive (the public one, defined in pg_dump_structs.h) and cast to
ArchiveHandle internally.  However, since pg_backup_db.h is not used
much, I guess it doesn't really matter.

There are some further (smaller) improvements that could be made if we
really cared about it, but I'm satisfied with this.

(I just realized after writing all this that I could achieve exactly the
same by putting the contents of the new pg_dump_structs.h in pg_backup.h
instead.  If there are no strong opinions to the contrary, I'm inclined
to do it that way instead, but I want to post it this way to gather
opinions in case anyone cares.)

--
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Thom Brown
Дата:
Сообщение: Re: Context lenses to set/get values in json values.
Следующее
От: Robert Haas
Дата:
Сообщение: Re: pg_background (and more parallelism infrastructure patches)