| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | exclusion(at)gmail(dot)com |
| Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org, Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Subject: | Re: BUG #17056: Segmentation fault on altering the type of the foreign table column with a default |
| Date: | 2021-06-10 22:10:29 |
| Message-ID: | 1806408.1623363029@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> CREATE FOREIGN DATA WRAPPER dummy;
> CREATE SERVER s0 FOREIGN DATA WRAPPER dummy;
> CREATE FOREIGN TABLE ft1 (c1 integer NOT NULL) SERVER s0;
> ALTER FOREIGN TABLE ft1 ADD COLUMN c8 integer DEFAULT 0;
> ALTER FOREIGN TABLE ft1 ALTER COLUMN c8 TYPE char(10);
Hmm. The equivalent DDL on a plain table works fine, but this is
crashing in the code that manipulates attmissingval. I suspect some
confusion about whether a foreign table column should even *have*
attmissingval. Andrew, any thoughts?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2021-06-10 22:19:51 | Re: BUG #17057: Unexpected error: ERROR: unsupported target type: 0 |
| Previous Message | PG Bug reporting form | 2021-06-10 21:46:10 | BUG #17057: Unexpected error: ERROR: unsupported target type: 0 |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2021-06-10 22:55:05 | Re: BUG #17056: Segmentation fault on altering the type of the foreign table column with a default |
| Previous Message | Justin Pryzby | 2021-06-10 22:04:16 | Re: unnesting multirange data types |