On Thu, Jun 11, 2026 at 6:38 PM Marcos Pegoraro <[email protected]> wrote:
> Em qui., 11 de jun. de 2026 às 04:48, Akshay Joshi < > [email protected]> escreveu: > >> Fixed the issue above. The v5 patch is ready for review/testing. >> > > One thing I noticed, though I'm not sure if it's the point here, is that > it's not possible to extract only the foreign keys or only the triggers > from the table. So if we want to extract the objects independently by type, > we would need to have all the return types as optional, and we could have > more granularity in the return types. > > Just like you have... > if (!ctx->include_indexes) > > You could have too > + if (!ctx->include_create_table) > + if (!ctx->include_foreign_keys) > + if (!ctx->include_primary_keys) > > Because only in this way can we more or less execute the dump behavior > here, which is to create all the tables beforehand, then primary keys, then > foreign keys, then triggers. > > I repeat, sorry if this is not the function's intended purpose. > I don't think per-contype flags are the right shape, though. The existing toggles group by catalog (indexes, constraints, rules, ...); splitting constraints into PK/FK/CHECK/UNIQUE/EXCLUDE/NOT NULL adds six flags on a second axis, and the function already carries nine. Only FKs have the cross-table dependency-ordering problem; the rest only reference the same table, so splitting them unlocks nothing new. On include_create_table, we are reconstructing the DDL for the table itself, so I don't think we should skip the CREATE TABLE statement. I'd rather always emit CREATE TABLE. > regards > Marcos > >
