Re: change "attnum <=0" to "attnum <0" for better reflect system attribute

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: jian he <jian(dot)universality(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: change "attnum <=0" to "attnum <0" for better reflect system attribute
Date: 2024-09-10 03:30:43
Message-ID: 3344596.1725939043@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

jian he <jian(dot)universality(at)gmail(dot)com> writes:
> get_attnum says:
> Returns InvalidAttrNumber if the attr doesn't exist (or is dropped).

> So I conclude that "attnum == 0" is not related to the idea of a system column.

attnum = 0 is also used for whole-row Vars. This is a pretty
unfortunate choice given the alternative meaning of "invalid",
but cleaning it up would be a daunting task (with not a whole
lot of payoff in the end, AFAICS). It's deeply embedded.

That being the case, you have to tread *very* carefully when
considering making changes like this.

> for example, ATExecColumnDefault, following code snippet,
> the second ereport should be "if (attnum < 0)"

> /* Prevent them from altering a system attribute */
> if (attnum <= 0)

I think that's just fine as-is. Sure, the == case is unreachable,
but it is very very common to consider whole-row Vars as being more
like system attributes than user attributes. In this particular
case, for sure we don't want to permit attaching a default to a
whole-row Var. So I'm content to allow the duplicative rejection.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2024-09-10 04:04:00 Re: Use streaming read API in ANALYZE
Previous Message jian he 2024-09-10 03:16:34 change "attnum <=0" to "attnum <0" for better reflect system attribute