Re: proposal: possibility to read dumped table's name from file
Justin Pryzby <pryzby@telsasoft.com>
From: Justin Pryzby <pryzby@telsasoft.com>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: pgsql-hackers@postgresql.org
Date: 2020-09-03T19:48:02Z
Lists: 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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix array subscript warnings
- 17935e1fdf0a 17.0 landed
-
Read include/exclude commands for dump/restore from file
- a5cf808be55b 17.0 landed
-
Allow records to span multiple lines in pg_hba.conf and pg_ident.conf.
- 8f8154a503c7 14.0 cited