Обсуждение: Unused variable found in AttrDefaultFetch
Hi,
I was looking at AttrDefaultFetch and saw that the variable found is never read.
I think it can be removed. See attached patch.
Cheers
Вложения
On Sun, Apr 4, 2021 at 8:14 AM Zhihong Yu <zyu@yugabyte.com> wrote: > > Hi, > I was looking at AttrDefaultFetch and saw that the variable found is never read. > > I think it can be removed. See attached patch. +1 to remove it and the patch LGTM. For reference, below is the commit that removed last usage of "found" variable: commit 16828d5c0273b4fe5f10f42588005f16b415b2d8 Author: Andrew Dunstan <andrew@dunslane.net> Date: Wed Mar 28 10:43:52 2018 +1030 Fast ALTER TABLE ADD COLUMN with a non-NULL default Currently adding a column to a table with a non-NULL default results in a rewrite of the table. For large tables this can be both expensive and disruptive. This patch removes the need for the rewrite as long as the @@ -4063,10 +4125,6 @@ AttrDefaultFetch(Relation relation) systable_endscan(adscan); heap_close(adrel, AccessShareLock); - - if (found != ndef) - elog(WARNING, "%d attrdef record(s) missing for rel %s", - ndef - found, RelationGetRelationName(relation)); } With Regards, Bharath Rupireddy. EnterpriseDB: http://www.enterprisedb.com
On Sun, Apr 04, 2021 at 10:13:26AM +0530, Bharath Rupireddy wrote: > +1 to remove it and the patch LGTM. Indeed, there is no point to keep that around. I'll go clean up that as you propose. -- Michael
Вложения
Michael Paquier <michael@paquier.xyz> writes: > On Sun, Apr 04, 2021 at 10:13:26AM +0530, Bharath Rupireddy wrote: >> +1 to remove it and the patch LGTM. > Indeed, there is no point to keep that around. I'll go clean up that > as you propose. What Andrew was suggesting in the other thread might well result in putting it back. I'd hold off till that decision is made. regards, tom lane
Andrew:
Can you chime in which direction to go ?
Once consensus is reached, I can provide a new patch, if needed.
Cheers
On Sat, Apr 3, 2021 at 9:54 PM Michael Paquier <michael@paquier.xyz> wrote:
On Sun, Apr 04, 2021 at 10:13:26AM +0530, Bharath Rupireddy wrote:
> +1 to remove it and the patch LGTM.
Indeed, there is no point to keep that around. I'll go clean up that
as you propose.
--
Michael
On 4/4/21 9:39 AM, Zhihong Yu wrote: > Andrew: > Can you chime in which direction to go ? > > Once consensus is reached, I can provide a new patch, if needed. > > Cheers > > [ please don't top-post ] I don't think we need a new patch. We'll clean this up one way or another as part of the cleanup on the other thread. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
Andrew:
Can you let me know which thread you were referring to?
I navigated the thread mentioned in your commit. It has been more than 3 years since the last response:
Can you let me know the current plan ?
Cheers
On Sun, Apr 4, 2021 at 8:13 AM Andrew Dunstan <andrew@dunslane.net> wrote:
On 4/4/21 9:39 AM, Zhihong Yu wrote:
> Andrew:
> Can you chime in which direction to go ?
>
> Once consensus is reached, I can provide a new patch, if needed.
>
> Cheers
>
>
[ please don't top-post ]
I don't think we need a new patch. We'll clean this up one way or
another as part of the cleanup on the other thread.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
I found the recent thread under 'ALTER TABLE ADD COLUMN fast default' which hasn't appeared in the message chain yet.
I will watch that thread.
Cheers
On Sun, Apr 4, 2021 at 8:47 AM Zhihong Yu <zyu@yugabyte.com> wrote:
Andrew:Can you let me know which thread you were referring to?I navigated the thread mentioned in your commit. It has been more than 3 years since the last response:Can you let me know the current plan ?CheersOn Sun, Apr 4, 2021 at 8:13 AM Andrew Dunstan <andrew@dunslane.net> wrote:
On 4/4/21 9:39 AM, Zhihong Yu wrote:
> Andrew:
> Can you chime in which direction to go ?
>
> Once consensus is reached, I can provide a new patch, if needed.
>
> Cheers
>
>
[ please don't top-post ]
I don't think we need a new patch. We'll clean this up one way or
another as part of the cleanup on the other thread.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
Zhihong Yu <zyu@yugabyte.com> writes: > Andrew: > Can you let me know which thread you were referring to? I assume he meant https://www.postgresql.org/message-id/flat/31e2e921-7002-4c27-59f5-51f08404c858%402ndQuadrant.com whih was last added to just moments ago. regards, tom lane