|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>|
|Subject:||Re: Allowing ALTER TYPE to change storage strategy|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
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
|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?|