Re: BUG #19848: BEGIN ATOMIC with unnamed/OUT params breaks restore and pg_upgrade

Atisss hh <125atishprak(at)gmail(dot)com> writes:
> I tested your patch on current master. All the cases from my report now
> create, dump and restore with identical results, and the core regression
> tests (243) and plsample pass. pg_upgrade from a patched build to a patched
> build works. Upgrading from 18.6 still fails with the empty identifier,
> since the old server does the deparsing, so this would also need
> backpatching to 18 to help pg_upgrade from there.

Yeah, it needs back-patching. I did that and pushed it.

> Agreed that the q2 case is a scoping problem and not part of this bug.
> I don't have a better idea than printing $n, since any qualified name
> can be captured by a FROM item with the same name.

I'll wait to see if Peter has a better idea before doing anything
about that part. The problem would only arise with a function name
that matches a table alias in some query within the function;
which is certainly possible but it must not be common, else we'd
have heard about this years ago.

regards, tom lane