Re: clean up docs for v12

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: clean up docs for v12
Дата
Msg-id 20190422182253.zhfmb77ybgnmsaiw@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: clean up docs for v12  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi,

On 2019-04-22 13:18:18 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> >> (Possibly I'd not think this if I weren't fresh off a couple of days
> >> with my nose in the ALTER TABLE SET NOT NULL code.  But right now,
> >> I think that believing that that code does not and never will have
> >> any bugs is just damfool.)
> 
> > But there's plenty places where we rely on NOT NULL actually working?
> 
> I do not think there are any other places where we make this particular
> assumption.

Sure, not exactly the assumtion that JITed deforming benefits from, but
as far as I can tell, plenty things would be broken just as well if we
allowed NOT NULL columns to not be present (whether "physically" present
or present via atthasmissing) for tuples in a table. Fast defaults
wouldn't work, Assert(!isnull) checks would fire, primary keys would be
broken etc.



> In hopes of putting some fear into you too, I exhibit the following
> behavior, which is not a bug according to our current definitions:
> 
> regression=# create table pp(f1 int);
> CREATE TABLE
> regression=# create table cc() inherits (pp);
> CREATE TABLE
> regression=# insert into cc values(1);
> INSERT 0 1
> regression=# insert into cc values(2);
> INSERT 0 1
> regression=# insert into cc values(null);
> INSERT 0 1
> regression=# alter table pp add column f2 text;
> ALTER TABLE
> regression=# alter table pp add column f3 text;
> ALTER TABLE
> regression=# alter table only pp alter f3 set not null;
> ALTER TABLE
> regression=# select * from pp;
>  f1 | f2 | f3 
> ----+----+----
>   1 |    | 
>   2 |    | 
>     |    | 
> (3 rows)
> 
> The tuples coming out of cc will still have natts = 1, I believe.
> If they were deformed according to pp's tupdesc, there'd be a
> problem.  Now, we shouldn't do that, because this is not the only
> possible discrepancy between parent and child tupdescs --- but
> I think this example shows that attnotnull is a lot spongier
> than you are assuming, even without considering the possibility
> of outright bugs.

Unortunately it doesn't really put the fear into me - given that
attribute numbers don't even have to match between inheritance children,
making inferrences about the length of the NULL bitmap seems peanuts
compared to the breakage of using the wrong tupdesc to deform.

Greetings,

Andres Freund



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: clean up docs for v12
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: block-level incremental backup