Re: BUG #17530: pg_dump comment on triggers is "off" by comparison to all of the other objects...
От | Tom Lane |
---|---|
Тема | Re: BUG #17530: pg_dump comment on triggers is "off" by comparison to all of the other objects... |
Дата | |
Msg-id | 3760003.1655958558@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #17530: pg_dump comment on triggers is "off" by comparison to all of the other objects... (Julien Rouhaud <rjuju123@gmail.com>) |
Список | pgsql-bugs |
Julien Rouhaud <rjuju123@gmail.com> writes: > On Wed, Jun 22, 2022 at 11:05:45PM +0000, PG Bug reporting form wrote: >> It's "change_log"<space>"id_change_log"; but the actual trigger name is >> "id_change_log" on the table "change_log" > That's expected, the name in the comment has a qualifier when the object name > itself isn't guaranteed to be unique, with the format > "$table_name $trigger_name" > This is done similarly for all object types that don't have a guarantee of > unique name (policies, rules...). Right. A couple further observations: * The relevant object names here are those of the table and trigger. The OP seems to be confusing this with the name of the function that the trigger uses --- but that could be completely different. * There's not been any attempt to make the comment labels be guaranteed-unique or machine-parseable. If, say, you made a table or trigger name that contains a space, it'd be hard to tell by looking at the pg_dump comment which space separates the table name from the trigger name, versus which one(s) are part of one of those names. If we were doing this from scratch today we'd probably be more rigorous ... but it's been like this for twenty-ish years, and I doubt there's a lot of appetite for redefining it now. regards, tom lane
В списке pgsql-bugs по дате отправления: