From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: mapping object names to role IDs |
Date: | 2010-05-23 18:05:00 |
Message-ID: | AANLkTim7QyFfVb_ZF5DXJyraLBo38w6E9tj-x6C_jHOo@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, May 23, 2010 at 1:39 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Sun, May 23, 2010 at 11:30 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> I think both Stephen and I are saying we don't see merit in that.
>>> Moving around pre-existing functions won't accomplish much except
>>> causing include-list churn. Let's just standardize the names/APIs
>>> and be done.
>
>> Where do we put the new functions?
>
> Probably in files that are already concerned with each object type.
Not every object type has a file, and the existing functions are split
across three different directories, sometimes in files that don't
really pertain to the object type being dealt with. I think this is
going to be difficult to maintain if we intentionally spread out the
parallel code across essentially the entire backend. But I guess I
can code it up and we can argue about it then.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-05-23 18:17:20 | Re: mapping object names to role IDs |
Previous Message | Tom Lane | 2010-05-23 17:39:33 | Re: mapping object names to role IDs |