How about a warning in docs for uncautious DBA's?
2011/10/13 Bruce Momjian
>
> I assume this should _not_ be added as a TODO.
--
Daniel Cristian Cruz
クルズ クリスチアン ダニエル
I assume this should _not_ be added as a TODO.
---
Greg Stark wrote:
> On Tue, Jun 7, 2011 at 3:33 PM, Tom Lane wrote:
> > Greg Stark writes:
> >> On Jun 3, 2011 4:20 PM, "Tom Lane" wrote:
> >>> I'm inclined to write this
On Tue, Jun 7, 2011 at 3:33 PM, Tom Lane wrote:
> Greg Stark writes:
>> On Jun 3, 2011 4:20 PM, "Tom Lane" wrote:
>>> I'm inclined to write this off as "so don't do that". There's nothing
>>> that pg_dump can do to make this work: it has to use the USING syntax
>>> for the join, and that doesn'
Greg Stark writes:
> A lot of work has gone into making pg_dump/pg_restore guarantee that
> they'll always produce a copy of the database, even if you've done odd
> things like change the lower bounds of your arrays. A lot of this was
> from before the days of PITR when pg_dump/pg_restore was the
Greg Stark writes:
> On Jun 3, 2011 4:20 PM, "Tom Lane" wrote:
>> I'm inclined to write this off as "so don't do that". There's nothing
>> that pg_dump can do to make this work: it has to use the USING syntax
>> for the join, and that doesn't offer any way to qualify the column name
>> on just o
On Jun 3, 2011 4:20 PM, "Tom Lane" wrote:
>
> > [ view definition now fails due to multiple "id_a" columns ]
>
> I'm inclined to write this off as "so don't do that". There's nothing
> that pg_dump can do to make this work: it has to use the USING syntax
> for the join, and that doesn't offer any
