|From:||Euler Taveira <euler(at)timbira(dot)com(dot)br>|
|To:||Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>|
|Subject:||Re: move collation import to backend|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 18-12-2016 18:30, Peter Eisentraut wrote:
> Updated patch with that fix.
Peter, I reviewed and improved your patch.
* I document the new function. Since collation is a database object, I
chose "Database Object Management Functions" section.
* I've added a check to any-encoding database because I got 'FATAL:
collation "C" already exists' on Debian 8, although, I didn't get on
CentOS 7. The problem is that Debian has two locales for C (C and
C.UTF-8) and CentOS has just one (C).
* I've added OidIsValid to test the new collation row.
* I've changed the parameter order. Schema seems more important than
if_not_exists. Also, we generally leave those boolean parameters for the
end of list. I don't turn if_not_exists optional but IMO it would be a
good idea (default = true).
* You removed some #if and #ifdef while moving things around. I put it back.
* You didn't pgident some lines of code but I'm sure you didn't for a
small patch footprint.
* I didn't test on Windows.
* As a last comment, you set cost = 100 and it seems reasonable because
it lasts 411 ms to scan/load 923 collations in my slow VM. However,
successive executions takes ~1200 ms.
I'm attaching the complete and also a patch at the top of your last patch.
Euler Taveira Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
|Next Message||Erik Rijkers||2017-01-10 03:08:18||Re: WIP: Covering + unique indexes.|
|Previous Message||Michael Paquier||2017-01-10 02:01:00||Re: Support for pg_receivexlog --format=plain|tar|