On 10/31/17, Tom Lane wrote:
> Yeah, there are quite a few unqualified casts in pg_dump, but AFAICS
> all the rest are OK because the search_path is just pg_catalog.
>
> But I did find psql's describe.c making a similar mistake :-(.
> Pushed that along with your fix.
>
> rega
Vitaly Burovoy writes:
> I left an other "NULL::name AS rolname" at
> src/bin/pg_dump/pg_dump.c:2978 because can't check (remoteVersion <
> 9) it and it is under strict "selectSourceSchema(fout,
> "pg_catalog");" schema set.
Yeah, there are quite a few unqualified casts in pg_dump, but AFAICS
On 10/31/17, Tom Lane wrote:
> Vitaly Burovoy writes:
>> Recently my colleagues found a bug.
>
>> - "SELECT 'bigint'::name AS
>> sequence_type, "
>> + "SELECT
>> 'bigint'::pg_catalog.name AS sequence_type,
Vitaly Burovoy writes:
> Recently my colleagues found a bug.
> - "SELECT 'bigint'::name AS
> sequence_type, "
> + "SELECT
> 'bigint'::pg_catalog.name AS sequence_type,
Good catch, but I think we could
Hello, hackers!
Recently my colleagues found a bug.
They could not migrate from PG9.5 to PG10 due to error during
pg_upgrage (the same as in the "reproduce" part below).
An investigation showed there is a table "name" in the same schema
where the dumped sequence is located and the PG tries to unpa
