[PATCH v1] Fix for Bug#19724 - ALTER TYPE ... ALTER ATTRIBUTE triggers internal error for base type of domain with check

Hi,

The following bug was reported in [1]

```
CREATE TYPE rt AS (i int);
CREATE DOMAIN dt AS int CHECK ((ROW(value)::rt).i > 0);
ALTER TYPE rt ALTER ATTRIBUTE i TYPE bigint;

triggers an internal
ERROR: XX000: could not identify relation associated with constraint 16390
LOCATION: ATPostAlterTypeCleanup, tablecmds.c:16147

Reproduced starting from af20e2d72.

```

I am not sure how common this scenario is but I investigated the
history of the commit af20e2d72. LLM pointed me to [2] from 2017.

The thread mentions a similar case in the email but it isn't covered
in the test cases.

```
regression=# create type comptype as (r float8, i float8);
CREATE TYPE
regression=# create domain silly as float8 check
((row(value,0)::comptype).r > 0);
CREATE DOMAIN
regression=# alter type comptype alter attribute r type varchar;
ERROR: cache lookup failed for relation 0
```

Therefore I am attaching a patch file with a proposed fix. The issue
stems from the fact that for a domain constraint, we currently look
for the domain's base type and the corresponding relid. But if the
domain is over a primitive type like int, there is no relid. And
therefore it fails.

My understanding of code is that this relid is only being used in
ATPostAlterTypeParse to unqueue the entry corresponding to the type
being altered.

So in this patch instead of getting the relid from the domain, we use
the relid of the type being altered.

I tested changing int to bigint and text to ensure it passes in the
first case and fails in the second.

Please take a look and let me know what you think.

[1] https://www.postgresql.org/message-id/flat/19724-58468097b5b17d10%40postgresql.org
[2] https://www.postgresql.org/message-id/flat/30656.1509128130%40sss.pgh.pa.us

Regards & Thanks,
Nitin Motiani
Google