Re: removing datlastsysoid

On 5/16/22 11:19 AM, Alvaro Herrera wrote: On 2022-May-16, David Steele wrote: On 5/16/22 10:26 AM, Tom Lane wrote: I think that when we approach the point where the system OID range is saturated, we'll give up the principle of system OIDs being globally unique instead of doing that. There'

Re: removing datlastsysoid

On 2022-May-16, David Steele wrote: > On 5/16/22 10:26 AM, Tom Lane wrote: > > I think that when we approach the point where the system OID range > > is saturated, we'll give up the principle of system OIDs being > > globally unique instead of doing that. There's no fundamental > > reason why un

Re: removing datlastsysoid

On 5/16/22 10:26 AM, Tom Lane wrote: Dave Page writes: On Mon, 16 May 2022 at 15:06, David Steele wrote: Out solution was to use the constant: #define FirstNormalObjectId 16384 And treat anything below that as a system oid. This constant has not changed in a very long time (i

Re: removing datlastsysoid

Dave Page writes: > On Mon, 16 May 2022 at 15:06, David Steele wrote: >> Out solution was to use the constant: >> >> #define FirstNormalObjectId 16384 >> >> And treat anything below that as a system oid. This constant has not >> changed in a very long time (if ever) but we added it

Re: removing datlastsysoid

On Mon, 16 May 2022 at 15:06, David Steele wrote: > On 5/16/22 9:43 AM, Dave Page wrote: > > > > > > On Thu, 20 Jan 2022 at 14:03, Robert Haas > > wrote: > > > > On Mon, Jan 17, 2022 at 3:43 PM Tom Lane > > wrote: > > > +1.

Re: removing datlastsysoid

On 5/16/22 9:43 AM, Dave Page wrote: On Thu, 20 Jan 2022 at 14:03, Robert Haas > wrote: On Mon, Jan 17, 2022 at 3:43 PM Tom Lane mailto:t...@sss.pgh.pa.us>> wrote: > +1.  Another reason to get rid of it is that it has nothing to do > with the system

Re: removing datlastsysoid

On Thu, 20 Jan 2022 at 14:03, Robert Haas wrote: > On Mon, Jan 17, 2022 at 3:43 PM Tom Lane wrote: > > +1. Another reason to get rid of it is that it has nothing to do > > with the system OID ranges defined in access/transam.h. > > Agreed. Thanks for looking. Committed. > So we just ran into t

Re: removing datlastsysoid

On Mon, Jan 17, 2022 at 3:43 PM Tom Lane wrote: > +1. Another reason to get rid of it is that it has nothing to do > with the system OID ranges defined in access/transam.h. Agreed. Thanks for looking. Committed. -- Robert Haas EDB: http://www.enterprisedb.com

Re: removing datlastsysoid

Robert Haas writes: > Since that doesn't seem like an especially good idea, PFA a patch to > remove it. Note that, even prior to that commit, it wasn't being used > for anything when dumping modern servers, so it would still have been > OK to remove it from the current system catalog structure. No

removing datlastsysoid

Hi, While reviewing another patch, I noticed that it slightly adjusted the treatment of datlastsysoid. That made me wonder what datlastsysoid is used for, so I started poking around and discovered that the answer, at least insofar as I can determine, is "nothing". The documentation claims that the