| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: PostgreSQL vs SQL Standard |
| Date: | 2018-06-10 15:19:39 |
| Message-ID: | 3530.1528643979@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> Oh wow, I hadn't noticed that dropping a function referenced from a
> domain's default or constraint drops the whole domain rather than just
> removing the default or constraint the way it would with a table.
Ouch. Seems like possibly a bug ... shouldn't we make only that
constraint depend on the function? But that's orthogonal to the
DROP DOMAIN behavior you were describing.
> (If it were not the case, then the only way we'd end up cascading to
> dropping a domain would be if we dropped the base type, in which case
> the columns are going to go away anyway)
Nope, drop schema and drop owned by (at the least) could also cascade to
a domain.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2018-06-10 15:32:56 | Re: PostgreSQL vs SQL Standard |
| Previous Message | Andrew Dunstan | 2018-06-10 14:41:26 | CF bug fix items |