From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Peter Geoghegan <pg(at)heroku(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Recently added typedef "string" is a horrid idea |
Date: | 2016-02-07 15:18:56 |
Message-ID: | CA+TgmoYKMKZxMnuw1o=Wei_U-jw76nvsU8HDaR-Zj9Q=6XniEg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Feb 7, 2016 at 8:03 AM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> On Sat, Feb 6, 2016 at 2:11 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Remember that the effects of typedef names are
>> *global*, so far as pgindent is concerned; not only varlena.c will
>> be affected.
>
> I'll remember that in the future.
>
>> Please rename this typedef with some less-generic name. Probably
>> some of the other identifiers added in the same commit should be
>> adjusted to match.
>
> I suggest "VarString". All the text SortSupport routines were renamed
> to match a pattern of "varstr.*" as part of the commit you mention.
>
> The implication that was intended by the rename is that the relevant
> routines are responsible for about the same cases as the cases handled
> by varstr_cmp(). I tend to mostly think of the text type when looking
> at varstr_cmp(), but it's also used by jsonb, for example, as well as
> char(n). It has a broader purpose; it is used by collatable types
> generally. So, a rename to "VarString" probably makes sense,
> independent of your pgindent concern.
>
> If this sounds like a good idea, I'll produce a patch soon.
VarString is OK with me - I'm not personally wedded to any specific
proposal here.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-02-07 15:23:15 | pgsql: Introduce group locking to prevent parallel processes from deadl |
Previous Message | Filip Rembiałkowski | 2016-02-07 15:00:46 | Re: proposal: make NOTIFY list de-duplication optional |