From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Allowing ALTER TYPE to change storage strategy |
Date: | 2020-03-04 18:39:58 |
Message-ID: | 30065.1583347198@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> writes:
> On Mon, Mar 02, 2020 at 02:11:10PM -0500, Tom Lane wrote:
>> In the v3 patch below, I've ripped out the ALTER DOMAIN syntax on
>> the assumption that we'd do the latter; but I've not written the
>> cascade recursion logic, because that seemed like a lot of work
>> to do in advance of having consensus on it being a good idea.
> I do agree we should do the latter, i.e. maintain the assumption that
> domains have the same properties as their base type. I can't think of a
> use case for allowing them to differ, it just didn't occur to me there
> is this implicit assumption when writing the patch.
Here's a v4 that is rebased over HEAD + the OPAQUE-ectomy that I
proposed at <4110(dot)1583255415(at)sss(dot)pgh(dot)pa(dot)us>, plus it adds recursion
to domains, and I also added the ability to set typmod I/O and
analyze functions, which seems like functionality that somebody
could possibly wish to add to a type after-the-fact much like
binary I/O.
I thought about allowing the basic I/O functions to be replaced as
well, but I couldn't really convince myself that there's a use-case
for that. In practice you'd probably always just change the
behavior of the existing I/O functions, not want to sub in new ones.
(I kind of wonder, actually, whether there's a use-case for the
NONE options here at all. When would you remove a support function?)
Of the remaining CREATE TYPE options, "category" and "preferred"
could perhaps be changeable but I couldn't get excited about them.
All the others seem like there are gotchas --- for example,
changing a type's collatable property is much harder than it
looks because it'd affect stored views. So this seems like a
reasonable stopping point.
I think this is committable --- how about you?
I've included the OPAQUE-ectomy patches below so that the cfbot
can test this, but they're the same as in the other thread.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
0001-simplify-CREATE-TYPE-1.patch | text/x-diff | 21.6 KB |
0002-remove-remaining-traces-of-OPAQUE-1.patch | text/x-diff | 16.8 KB |
0003-alter-type-v4.patch | text/x-diff | 43.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Nikolay Shaplov | 2020-03-04 19:58:31 | Re: [PATCH] Finally split StdRdOptions into HeapOptions and ToastOptions |
Previous Message | Andres Freund | 2020-03-04 17:40:03 | Re: pgbench: option delaying queries till connections establishment? |