Re: Command order bug in pg_dump
От | Kirill Reshke |
---|---|
Тема | Re: Command order bug in pg_dump |
Дата | |
Msg-id | CALdSSPj4V03H77a5MKCEuyuonYYMx3o=nepXdgsUaNxn2WrUWA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Command order bug in pg_dump (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Command order bug in pg_dump
|
Список | pgsql-bugs |
On Mon, 21 Apr 2025 at 19:56, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Doesn't seem to be a new problem, either ... this trace is against > v13. Sure, repro was on 12=>13 pg_upgrade. > We could fool around with the generation rule for the child constraint's name, but fundamentally we're infringing on user namespace here, so I think that's likely to just move the problem cases around. My view of this problem is that pg_dump fails its purpose (to produce restorable dump) because... Lack of control? What if we can force inherited child constraint names? So, along with AT ADD CONSTRAINT, we can provide a list of names and say: instead of using a constraint name generation rule, the server should choose these names in order. I understand this is too much code for this minor matter, and the fix will be probably just to change generation rule. > Why do we need this child pg_constraint entry at all? Currently no idea. > In any case, it's pretty awful that we make these entries but \d does not show them. Okay... Perhaps, but since the user did not specifically request this, perhaps we shouldn't display it. -- Best regards, Kirill Reshke
В списке pgsql-bugs по дате отправления: