Re: using index or check in ALTER TABLE SET NOT NULL - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: using index or check in ALTER TABLE SET NOT NULL
Date
Msg-id 20171129155812.GO4628@tamriel.snowman.net
Whole thread Raw
In response to Re: using index or check in ALTER TABLE SET NOT NULL  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: using index or check in ALTER TABLE SET NOT NULL  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.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

pgsql-hackers by date:

Previous
From: Sergei Kornilov
Date:
Subject: Re: using index or check in ALTER TABLE SET NOT NULL
Next
From: Petr Jelinek
Date:
Subject: Re: [HACKERS] Walsender timeouts and large transactions