Re: [HACKERS] move collation import to backend

Jeff Janes writes: > With this commit, I'm getting 'make check' fail at initdb with the error: > 2017-01-18 07:47:50.565 PST [43691] FATAL: collation "aa_ER@saaho" for > encoding "UTF8" already exists Yeah, so are large chunks of the buildfarm. Having now read the patch,

Re: [HACKERS] move collation import to backend

On Tue, Jan 17, 2017 at 9:05 AM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 1/9/17 10:04 PM, Euler Taveira wrote: > > On 18-12-2016 18:30, Peter Eisentraut wrote: > >> Updated patch with that fix. > >> > > Peter, I reviewed and improved your patch. > > > > * I document the

Re: [HACKERS] move collation import to backend

On 1/9/17 10:04 PM, Euler Taveira wrote: > 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"

Re: [HACKERS] move collation import to backend

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

Re: [HACKERS] move collation import to backend

On 11/30/16 8:18 AM, Peter Eisentraut wrote: >> It seems not to be project style to have prototypes in the middle of the >> file... > > OK, will fix. Updated patch with that fix. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA,

Re: [HACKERS] move collation import to backend

On Thu, Dec 1, 2016 at 12:18 AM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > > > > + > +Datum pg_import_system_collations(PG_FUNCTION_ARGS); > + > +Datum > +pg_import_system_collations(PG_FUNCTION_ARGS) > +{ > >>> > >>> Uh? > >> > >> Required to

Re: [HACKERS] move collation import to backend

On 11/29/16 2:53 PM, Andres Freund wrote: > On 2016-11-29 12:16:37 -0500, Peter Eisentraut wrote: >> On 11/12/16 10:38 AM, Andres Freund wrote: /* * Also forbid matching an any-encoding entry. This test of course is not * backed up by the unique index, but it's not

Re: [HACKERS] move collation import to backend

Andres Freund writes: > On 2016-11-29 12:16:37 -0500, Peter Eisentraut wrote: >> Required to avoid compiler warning about missing prototype. > It seems not to be project style to have prototypes in the middle of the > file... I agree. Please put that in builtins.h, if you

Re: [HACKERS] move collation import to backend

On 2016-11-29 12:16:37 -0500, Peter Eisentraut wrote: > On 11/12/16 10:38 AM, Andres Freund wrote: > >>/* > >> * Also forbid matching an any-encoding entry. This test of course is > >> not > >> * backed up by the unique index, but it's not a problem since we don't > >> * support

Re: [HACKERS] move collation import to backend

On 11/12/16 10:38 AM, Andres Freund wrote: > E.g. what if previously present collations are now unavailable? You get an error message when you try to use the collation. I think that is a different class of problems. >> >> /* >> * Also forbid matching an any-encoding entry. This

Re: [HACKERS] move collation import to backend

Hi, On 2016-10-27 21:56:53 -0400, Peter Eisentraut wrote: > Currently, initdb parses locale -a output to populate pg_collation. If > additional collations are installed in the operating system, it is not > possible to repeat this process, only by doing each step manually. So I > propose to move

[HACKERS] move collation import to backend

Currently, initdb parses locale -a output to populate pg_collation. If additional collations are installed in the operating system, it is not possible to repeat this process, only by doing each step manually. So I propose to move this to a backend function that can be called separately, and have