On 2019-Apr-24, David Rowley wrote: > On Wed, 24 Apr 2019 at 10:26, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > > If creating a partition, there is the additional rule that parent's > > tablespace overrides default_tablespace: > > > > a2. if there's a TABLESPACE clause, use that. > > b2. otherwise, if the parent has a tablespace, use that. > > c2. otherwise, if there's a default_tablespace, use that. > > d2. otherwise, use the database tablespace. > > e2. if we end up with the database tablespace, overwrite with 0. > > Wouldn't it just take the proposed pg_dump change to get that? rule > e2 says we'll store 0 in reltablespace, even if the user does > TABLESPACE pg_default, so there's no requirement to adjust the hack in > heap_create to put any additional conditions on when we set > reltablespace to 0, so it looks like none of the patching work you did > would be required to implement this. Right?
I'm not sure yet that 100% of the patch is gone, but yes much of it would go away thankfully. I do suggest we should raise an error if rule a3 hits and it mentions the database tablespace (I stupidly forgot this critical point in the previous email). I think astonishment is lesser that way. > The good part about that is that its consistent with what happens if > the user does TABLESPACE pg_default for any other object type that > supports tablespaces. i.e we always store 0. Yeah, it makes the whole thing a lot simpler. Note my note for further development of a feature (modelled after Robert's proposal) to allow the database tablespace to be specified, using either a separate pg_tablespace entry that means "use the database tablespace whatever that is" (Tom's suggestion), or a magic not-a-real-tablespace-OID number known to the code, such as 1 (Robert's). -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
