Re: pg_dump: Remove "blob" terminology
От | Robert Haas |
---|---|
Тема | Re: pg_dump: Remove "blob" terminology |
Дата | |
Msg-id | CA+TgmobsWzd3h24E3AciWodFC21FF1YCJB5HR=02aBNW_SUqpw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_dump: Remove "blob" terminology (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: pg_dump: Remove "blob" terminology
|
Список | pgsql-hackers |
On Sat, Dec 3, 2022 at 11:07 AM Andrew Dunstan <andrew@dunslane.net> wrote: > > Well, what this would lose is the ability to selectively restore > > individual large objects using "pg_restore -L". I'm not sure who > > out there might be depending on that, but if we assume that's the > > empty set I fear we'll find out it's not. So a workaround switch > > seemed possibly worth the trouble. I don't have a position yet > > on which way ought to be the default. > > OK, fair point. I suspect making the batched mode the default would gain > more friends than enemies. A lot of people probably don't know that selective restore even exists but it is an AWESOME feature and I'd hate to see us break it, or even just degrade it. I wonder if we can't find a better solution than bunching TOC entries together. Perhaps we don't need every TOC entry in memory simultaneously, for instance, especially things like LOBs that don't have dependencies. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: