Re: Unhappy thoughts about pg_dump and objects inherited from template1 - Mailing list pgsql-hackers

From Jan Wieck
Subject Re: Unhappy thoughts about pg_dump and objects inherited from template1
Date
Msg-id 200011091447.JAA01285@jupiter.jw.home
Whole thread Raw
In response to Re: Unhappy thoughts about pg_dump and objects inherited from template1  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Unhappy thoughts about pg_dump and objects inherited from template1  (Philip Warner <pjw@rhyme.com.au>)
Re: Unhappy thoughts about pg_dump and objects inherited from template1  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Unhappy thoughts about pg_dump and objects inherited from template1  (selkovjr@mcs.anl.gov)
List pgsql-hackers
Tom Lane wrote:
> Philip Warner <pjw@rhyme.com.au> writes:
> > Where would you store the value if not in pg_database?
>
> No other ideas at the moment.  I was just wondering whether there was any
> way to delete it entirely, but seems like we want to have the value for
> template0 available.  The old way of hardwiring knowledge into pg_dump
> was definitely not as good.
   To  make  pg_dump  failsafe,  we'd  IMHO  need  to freeze all   objects that come with template0 copying.
   For now we have oid's 1-16383 hardwired from the  bki  files.   Some  16384-xxxxx get allocated by initdb after
bootstrap,so   we just need to bump the oid counter at the end of initdb (by   some  bootstrap  interface  command)  to
lets  say 32768 and   reject any attempt to touch an object with a lower oid.
 


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #




pgsql-hackers by date:

Previous
From: Jan Wieck
Date:
Subject: Re: Unhappy thoughts about pg_dump and objects inherited from template1
Next
From: Don Baccus
Date:
Subject: Re: Text concat problem