Re: let ALTER COLUMN SET DATA TYPE cope with trigger dependency

Поиск
Список
Период
Сортировка
От jian he
Тема Re: let ALTER COLUMN SET DATA TYPE cope with trigger dependency
Дата
Msg-id CACJufxFjSGY2npNQjqsFxqa7H5tN-rRV1NuxXmFicGm+N-kh-w@mail.gmail.com
обсуждение исходный текст
Ответ на let ALTER COLUMN SET DATA TYPE cope with trigger dependency  (jian he <jian.universality@gmail.com>)
Список pgsql-hackers
hi.

v2-0001, v2-0002 is the same as [1].
The parameters relOid and refRelOid are removed from the CreateTrigger function
and instead added to the CreateTrigStmt structure.

The main reason is to avoid repeated name lookups.
In fact, we already did this in CreateTriggerFiringOn, see below code snippet.
If the OID is valid, use it preferentially; otherwise, fall back to resolving
the relation via the RangeVar.

```
    if (OidIsValid(relOid))
        rel = table_open(relOid, ShareRowExclusiveLock);
    else
        rel = table_openrv(stmt->relation, ShareRowExclusiveLock);

        if (OidIsValid(refRelOid))
        {
            LockRelationOid(refRelOid, AccessShareLock);
            constrrelid = refRelOid;
        }
        else if (stmt->constrrel != NULL)
            constrrelid = RangeVarGetRelid(stmt->constrrel, AccessShareLock,
                                           false);
```

v2-0003: is the actual implementation.
The general workflow would be as follows: collect all affected triggers,
retrieve their definitions, drop the existing triggers, and then recreate them.
Any comments associated with the triggers will also be dropped and recreated.

[1]: https://postgr.es/m/CACJufxFu7Y4FhVkaKT2Kaj8ym2T5TcwN93cR_6h4x66iLrSZ-Q@mail.gmail.com


--
jian
https://www.enterprisedb.com/

Вложения

В списке pgsql-hackers по дате отправления: