Re: Restore replication settings when modifying a field type

From: Quan Zongliang <quanzongliang(at)foxmail(dot)com>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Euler Taveira <euler(at)timbira(dot)com(dot)br>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Restore replication settings when modifying a field type
Date: 2020-01-15 00:30:42
Message-ID: ec12720a-b834-05d4-f7fb-ab69bcce7112@foxmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2020/1/3 17:14, Peter Eisentraut wrote:
> On 2019-11-01 04:39, Euler Taveira wrote:
>> ATExecAlterColumnType records everything that depends on the column
>> and for indexes it saves the definition (via pg_get_indexdef_string).
>> Definition is not sufficient for reconstructing the replica identity
>> information because there is not such keyword for replica identity in
>> CREATE INDEX. The new index should call relation_mark_replica_identity
>> to fix pg_index.indisreplident.
>
> Yeah, I don't think we need to do the full dance of reverse compiling
> the SQL command and reexecuting it, as the patch currently does.  That's
> only necessary for rebuilding the index itself.  For re-setting the
> replica identity, we can just use the internal API as you say.
>
> Also, a few test cases would be nice for this patch.
>

I'm a little busy. I'll write a new patch in a few days.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-01-15 00:37:30 Re: Add support for automatically updating Unicode derived files
Previous Message Tom Lane 2020-01-14 23:44:44 Re: planner support functions: handle GROUP BY estimates ?