From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Sergei Kornilov <sk(at)zsrv(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: using index or check in ALTER TABLE SET NOT NULL |
Date: | 2017-11-29 15:58:12 |
Message-ID: | 20171129155812.GO4628@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom,
* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > Isn't the first concern addressed by using SPI..?
>
> I did not look at the patch yet, but TBH if it uses SPI for sub-operations
> of ALTER TABLE I think that is sufficient reason to reject it out of hand.
You mean like what ALTER TABLE ... ADD FOREIGN KEY does?
> Doing things that way would create way too much of a vulnerability surface
> for code touching a partially-updated table. At minimum, we'd have to
> blow holes in existing protections like CheckTableNotInUse, and I think
> we'd be forever finding other stuff that failed to work quite right in
> that context. I do not want ALTER TABLE going anywhere near the planner
> or executor; I'm not even happy that it uses the parser (for index
> definition reconstruction).
That's more along the lines of the kind of response I was expecting
given the suggestion, and perhaps a good reason to just go with the
index-based lookup, when an index is available to do so with, but I'm
not entirely sure how this is different from how we handle foreign keys.
Thanks!
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Petr Jelinek | 2017-11-29 15:59:17 | Re: [HACKERS] Walsender timeouts and large transactions |
Previous Message | Sergei Kornilov | 2017-11-29 15:52:36 | Re: using index or check in ALTER TABLE SET NOT NULL |