Re: move collation import to backend

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: move collation import to backend
Date: 2016-11-30 13:18:20
Message-ID: 089bb119-cd29-9aa3-8271-8a7ceead5554@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 a problem since we don't
>>>> * support adding any-encoding entries after initdb.
>>>> */
>>>
>>> Note that this isn't true anymore...
>>
>> I think this is still correct, because the collation import does not
>> produce any any-encoding entries (collencoding = -1).
>
> Well, the comment "don't support adding any-encoding entries after
> initdb." is now wrong.

I think there is a misunderstanding. The comment says that we don't
support adding encodings that have collencoding = -1 after initdb. That
is still true. Note that the original comment as two "any"'s. With
this patch, we would now support adding collations with collencoding <>
-1 after initdb.

>
>>>> +
>>>> +Datum pg_import_system_collations(PG_FUNCTION_ARGS);
>>>> +
>>>> +Datum
>>>> +pg_import_system_collations(PG_FUNCTION_ARGS)
>>>> +{
>>>
>>> Uh?
>>
>> Required to avoid compiler warning about missing prototype.
>
> It seems not to be project style to have prototypes in the middle of the
> file...

OK, will fix.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2016-11-30 13:22:17 Re: Random number generation, take two
Previous Message Heikki Linnakangas 2016-11-30 12:59:44 Re: Radix tree for character conversion