On 3/21/18 02:51, Edmund Horner wrote: > I still think the number of completions on an empty string is a bit > too big, but I don't know what to omit. There are around 1700 > completions on the empty "postgres" database in my testing, and we > show the first 1000 (arbitrarily limited, as the generated SQL has > LIMIT 1000 but no ORDER BY). > > Should we just leave it as is? > > Whether we improve the filtering or not, I'm optimistic the feature > will be committed in this CF or the next.
I looked at this a bit now. I think it still needs some work. Some of the queries for older versions contain syntax errors that causes them not to work. For example, in 80100: "'internal'::regtype != ALL ([.proargtypes) " The query definition structures are missing a comma between selcondition and viscondition. This causes all the following fields to be misassigned. I'm not quite sure how it actually works at all some of the time. There might be another bug that offsets this one. I'd like to see a short comment what is different between each of the version queries. You had a list earlier in the thread. The selection of which functions to show can be further refined. I don't think the contents of pg_amproc and pg_cast should be excluded. Some of those functions are useful. Similarly for pg_operator.oprcode. Things like oprrest and oprjoin will already be excluded because they have "internal" arguments. Similarly for some columns in pg_aggregate. There are also additional pseudo-types that should be excluded. See pg_type.typtype = 'p', except some of those should not be excluded. Needs more thought. Considering these issues, I think it would be appropriate to move this patch to the next commitfest. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
