Greetings,
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > To me, adding a separate TOC entry for a thing that is not really a
> > separate object seems like a scary hack that might come back to bite
> > us. Unfortunately, I don't know enough about pg_dump to say exactly
> > how it might come back to bite us, which leaves wide open the
> > possibility that I am completely wrong.... I just think it's the
> > intention that archive entries correspond to actual objects in the
> > database, not commands that we want executed in some particular order.
>
> I agree, this seems like a moderately bad idea. It could get broken
> either by executing only one of the TOC entries during restore, or
> by executing them in the wrong order. The latter possibility could
> be forestalled by adding a dependency, which I do not see this hunk
> doing, which is clearly a bug. The former possibility would require
> user intervention, so maybe it's in the category of "if you break
> this you get to keep both pieces". Still, it's ugly.
Yeah, agreed.
> > If that criticism is indeed correct, then my proposal would be to
> > instead add a WITH OID = nnn option to CREATE DATABASE and allow it to
> > be used only in binary upgrade mode.
>
> If it's not too complicated to implement, that seems like an OK idea
> from here. I don't have any great love for the way we handle OID
> preservation in binary upgrade mode, so not doing it exactly the same
> way for databases doesn't seem like a disadvantage.
Also agreed on this, though I wonder- do we actually need to explicitly
make CREATE DATABASE q WITH OID = 1234; only work during binary upgrade
mode in the backend? That strikes me as perhaps doing more work than we
really need to while also preventing something that users might actually
like to do.
Either way, we'll need to check that the OID given to us can be used for
the database, I'd think.
Having pg_dump only include it in binary upgrade mode is fine though.
Thanks,
Stephen
