Tom,
Thanks for the insight, I didn't even consider the search path being an
issue and I should have. I saw it explicitly specified in other parts
of the dump and just assumed it was being done in the function as well.
For example, the CREATE statements in the dump output all specify the
"Nunya Business" writes:
> Thanks Tom. There are indeed circular references in the schema and the
> whole thing sort of doesn't pass the smell test, but this is my first
> look at it. The generated column on the table calls a function which
> selects from a view that references the table.
"Nunya Business" writes:
Within my schema there is a table that has a GENERATED ALWAYS column that calls a plpgsql
function. The called function has a "row type" variable declared that
references a view. While the schema itself functions properly day to day, and pg_dumpall
works as
On 12/5/22 11:49, Nunya Business wrote:
Good afternoon,
I've recently run into a weird issue that I'm trying to gather more data
on before sending an official bug report on the off chance that it's
already been addressed.
Within my schema there is a table that has a GENERATED ALWAYS column
"Nunya Business" writes:
> Within my schema there is a table that has a GENERATED ALWAYS column
> that calls a plpgsql function. The called function has a "row type"
> variable declared that references a view. While the schema itself
> functions properly day to day, and pg_dumpall works as
Good afternoon,
I've recently run into a weird issue that I'm trying to gather more data
on before sending an official bug report on the off chance that it's
already been addressed.
Within my schema there is a table that has a GENERATED ALWAYS column
that calls a plpgsql function. The
