Re: pgsql: Prevent redeclaration of typedef TocEntry. - Mailing list pgsql-committers

From Álvaro Herrera
Subject Re: pgsql: Prevent redeclaration of typedef TocEntry.
Date
Msg-id 202504042140.qo66ggw6wzsz@alvherre.pgsql
Whole thread Raw
In response to pgsql: Prevent redeclaration of typedef TocEntry.  (Nathan Bossart <nathan@postgresql.org>)
Responses Re: pgsql: Prevent redeclaration of typedef TocEntry.
List pgsql-committers
On 2025-Apr-04, Nathan Bossart wrote:

> Prevent redeclaration of typedef TocEntry.
> 
> Commit 9c02e3a986 added a forward declaration for this typedef that
> caused redeclarations, which is not valid in C99.  To fix, add some
> preprocessor guards to avoid a redefinition, as is done elsewhere
> (e.g., commit 382092a0cd).

Hmm, I have the impression that this results from some very old
untidyness in the pg_dump headers in general.  The fact that
DataDumperPtr is in pg_backup.h seems now more of an accident than
something we would really choose to do nowadays -- it's been that way
since pg_dump was introduced in commit 500b62b0570f apparently.  I'm
sure there were good reasons to have it there then.  But we've
restructured the pg_dump headers at least once, and as far as I can see
there aren't anymore.  AFAICS we could move both DefnDumperPtr and
DataDumperPtr typedefs to pg_backup_archiver.h, together with struct
_tocEntry (the only place where they are used), and we'd have less of a
mess here.  Then we don't need struct TocEntry in pg_backup.h anymore.

Plus, these function typedefs aren't really "public interface" for
pg_dump anyway (which is what pg_backup.h claims to be), so I think it
would be a sensible cleanup.  Patch attached.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
Thou shalt check the array bounds of all strings (indeed, all arrays), for
surely where thou typest "foo" someone someday shall type
"supercalifragilisticexpialidocious" (5th Commandment for C programmers)

Attachment

pgsql-committers by date:

Previous
From: Andrew Dunstan
Date:
Subject: pgsql: Fix a couple of error messages and tests for them
Next
From: Tom Lane
Date:
Subject: pgsql: functions.c: copy trees from source_list before parse analysis e