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
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 |