[pg] \restrict header + footer fix

[drew-u410]

• In postgres: 17.6 it looks like a \restrict header was added to pg_dump output.
  • Discussed in the release notes here: https://www.postgresql.org/docs/release/17.6/ under "Prevent pg_dump scripts from being used to attack the user running the restore (Nathan Bossart) §"
  • Change here: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=575f54d4c
• In using dbmate, it seems to be quite confused trying to parse these files with this \restrict header in them.
• The TrimLeadingSQLComments looks like maybe the best place to update and also trim these out.
• Confusingly, this change to pg_dump also ends a file with \unrestrict causing an issue parsing at the end too.

--

• The mysql test failure seems unrelated?

[dossy]

The MySQL test failure is due to this:

https://github.com/amacneil/dbmate/pull/673#issuecomment-3197769135

[dossy]

Disappointed that they didn't implement this with \set restrict <key> and \unset restrict which would have been 100% backwards compatible.

I'm not sure I like the idea of filtering all possible (future) meta-commands from pg_dump output vs. only removing \restrict and \unrestrict` because who knows what else will break in the future.

I also don't like the idea of filtering them out at all: if you're using a version of Postgres 17.6+ and it emits these, you are responsible for loading these into a version of Postgres that understands them, or removing them yourself. I don't think dbmate should be interfering with the output of the dump tool the user is using.

I feel like the right move here is to make dbmate's SQL parser smarter enough to not choke on what Postgres deems valid input to its own tools, and not filter them out.

Maybe I'm not quite understanding the issue, so if anyone else has thoughts, please chime in.

[drew-u410]

Yea- I truly wasn't sure. Feel free to discard / approach differently.

It just totally broke and I felt compelled to at least propose some solution for discussion.