Ok, I'll do it. > Сreating function A before function B results in a compilation error. On my part, this is an incorrect assumption. There are no compilation errors here. she just didn't recover from the first pass.
вс, 14 нояб. 2021 г. в 23:46, Tom Lane <t...@sss.pgh.pa.us>: > =?UTF-8?B?0JTQvNC40YLRgNC40Lkg0JjQstCw0L3QvtCy?= <firstdis...@gmail.com> > writes: > > вс, 14 нояб. 2021 г. в 22:31, Tom Lane <t...@sss.pgh.pa.us>: > >> Usually this is caused by being careless about search_path assumptions > >> in your functions ... but with no details, it's impossible to say > >> anything with certainty. > > > No, in this case it is not: > > Function A using function B. > > Сreating function A before function B results in a compilation error. > > Function B has no dependencies and is generated without errors. The > second > > run of the circuit creates function A. > > If I could specify a function dependency, it would change the order of > > recovery > > This is not "details", this is an evidence-free assertion. Please show > a concrete example of problematic functions. > > >> ... What minor release are you using? > > > PostgreSQL 14.1 (Debian 14.1-1.pgdg110+1) on x86_64-pc-linux-gnu, > compiled > > by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit > > pg_restote, pg_dump from this build > > Ok, so you're up to date all right. But again, you didn't say what > concrete problem you were having with a dump/restore of an identity > column. It works fine for me. > > regards, tom lane >
