Re: pg_dump of partitioned table not working.
От | Ron |
---|---|
Тема | Re: pg_dump of partitioned table not working. |
Дата | |
Msg-id | 58a08d1d-d538-4245-7a36-3808de4955b9@gmail.com обсуждение исходный текст |
Ответ на | Re: pg_dump of partitioned table not working. (Adrian Klaver <adrian.klaver@aklaver.com>) |
Список | pgsql-general |
On 12/2/20 6:54 PM, Adrian Klaver wrote: > On 12/2/20 4:38 PM, Ron wrote: >> On 12/2/20 6:21 PM, Adrian Klaver wrote: >>> On 12/2/20 4:13 PM, Ron wrote: >>>> On 12/2/20 6:08 PM, David G. Johnston wrote: >>>>> On Wed, Dec 2, 2020 at 5:06 PM Ron <ronljohnsonjr@gmail.com >>>>> <mailto:ronljohnsonjr@gmail.com>> wrote: >>> >>>>> That you were comparing apples and oranges - specifically that the >>>>> database you were dumping was empty but the one you were checking was >>>>> not. >>>>> >>>> >>>> While I could have shown the exact psql commands >>>> (/usr/lib/postgresql/12/bin/psql -p5433) it wasn't necessary. >>> >>> From the POV of the mailing list participants it was necessary as the >>> below constitutes hidden information we didn't have access to. When >>> presenting a issue explicit is better then implicit. I cannot count the >>> number of times issues where solved on this list when someone got around >>> to asking for a explicit command. >> >> Shame on me for assuming, based on the explicit pg_dump command in the >> example. > > The implied part was this: > > postgres=# \d+ measurement > > There was no indication of how you got there. You knew but we didn't and > given how many times it has happened that folks where looking at one > instance in one part of their problem report and another instance in > separate part of the report it is only prudent to ask. You're absolutely right. Like I said, shame on me. -- Angular momentum makes the world go 'round.
В списке pgsql-general по дате отправления: