Re: proposal: possibility to read dumped table's name from file
От | Justin Pryzby |
---|---|
Тема | Re: proposal: possibility to read dumped table's name from file |
Дата | |
Msg-id | 20200903194802.GP29760@telsasoft.com обсуждение исходный текст |
Ответ на | Re: proposal: possibility to read dumped table's name from file (Pavel Stehule <pavel.stehule@gmail.com>) |
Список | pgsql-hackers |
On Sun, Jul 05, 2020 at 10:08:09PM +0200, Pavel Stehule wrote: > st 1. 7. 2020 v 23:24 odesílatel Justin Pryzby <pryzby@telsasoft.com> napsal: > > > On Thu, Jun 11, 2020 at 09:36:18AM +0200, Pavel Stehule wrote: > > > st 10. 6. 2020 v 0:30 odesílatel Justin Pryzby <pryzby@telsasoft.com>> napsal: > > Also, your getline is dynamically re-allocating lines of arbitrary length. > > Possibly that's not needed. We'll typically read "+t schema.relname", > > which is > > 132 chars. Maybe it's sufficient to do > > char buf[1024]; > > fgets(buf); > > if strchr(buf, '\n') == NULL: error(); > > ret = pstrdup(buf); > > 63 bytes is max effective identifier size, but it is not max size of > identifiers. It is very probably so buff with 1024 bytes will be enough for > all, but I do not want to increase any new magic limit. More when dynamic > implementation is not too hard. Maybe you'd want to use a StrInfo like recent patches (8f8154a50). > Table name can be very long - sometimes the data names (table names) can be > stored in external storages with full length and should not be practical to > require truncating in filter file. > > For this case it is very effective, because a resized (increased) buffer is > used for following rows, so realloc should not be often. So when I have to > choose between two implementations with similar complexity, I prefer more > dynamic code without hardcoded limits. This dynamic hasn't any overhead. -- Justin
В списке pgsql-hackers по дате отправления: