mapping object names to role IDs
in [PgSql]
|
From: Robert Haas on 23 May 2010 13:18 On Sun, May 23, 2010 at 11:30 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >> On Sun, May 23, 2010 at 11:10 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >>> I'm with Stephen on this one. I agree that standardizing the function >>> names and behavior would be a good idea, but don't try to put them all >>> in one place. > >> Some of the existing functions are in lsyscache.c, some are in files >> in the commands directory, and some are in files in the parser >> directory; also, even between commands and parser, not every object >> type has its own file. It would be nice to bring some consistency to >> where the functions are located as well as what they do. Any thoughts >> on how to achieve that? > > 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? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 23 May 2010 13:39 Robert Haas <robertmhaas(a)gmail.com> writes: > On Sun, May 23, 2010 at 11:30 AM, Tom Lane <tgl(a)sss.pgh.pa.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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 23 May 2010 14:05 On Sun, May 23, 2010 at 1:39 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >> On Sun, May 23, 2010 at 11:30 AM, Tom Lane <tgl(a)sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 23 May 2010 14:17 Robert Haas <robertmhaas(a)gmail.com> writes: > 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. The only thing that seems really significantly parallel is the error message to be issued for object-not-found. I would suggest maybe putting the code in lsyscache.c, except that lsyscache functions generally are not expected to throw error on object-not-found. As for "not every object type has a file", there is certainly code someplace that would be calling these functions. Whereever (the preponderance of) such calls are would be an appropriate place for the function, IMO. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Peter Eisentraut on 26 May 2010 05:27 On sön, 2010-05-23 at 00:50 -0400, Robert Haas wrote: > Oid get_<object-type>_oid(List *qualname, bool missingok); > -or- > Oid get_<object-type>_oid(char *name, bool missingok); > > Thus get_database_oid and get_tablespace_oid would remain unchanged > except for taking a second argument, get_roleid and get_roleid_checked > would merge, and all of the others would change to match that style. If you are doing some refactoring work in that area, maybe you can also take care of the issue I talked about there: http://archives.postgresql.org/pgsql-hackers/2008-12/msg00725.php """ Our code contains about 200 copies of the following code: tuple = SearchSysCache[Copy](FOOOID, ObjectIdGetDatum(fooid), 0, 0, 0); if (!HeapTupleIsValid(tuple)) elog(ERROR, "cache lookup failed for foo %u", fooid); """ It looks like your proposal would reduce that number significantly. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 Prev: [HACKERS] mapping object names to role IDs Next: [PATCH] Move 'long long' check to c.h |