mapping object names to role IDs
in [PgSql]
|
From: Robert Haas on 23 May 2010 00:51 And of course I meant for the subject line to be "mapping object names to OIDs", not "role IDs". Sigh. ....Robert -- 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: Stephen Frost on 23 May 2010 10:28 * Robert Haas (robertmhaas(a)gmail.com) wrote: > Long story short, this is kind of a mess. I agree that it's a bit of a mess. > What I would propose is that we create a new source > file somewhere (maybe utils/cache), move all of the other functions of > this type there, give them standardized names, and provide them all > with an argument that specifies whether an error is to be thrown if > the object doesn't exist. Something which has come up in the past is that putting all the functions that do the same kind of thing, but operate on different types of objects, into the same backend file/area ends up meaning that such an area has an untold amount of knowledge about everything. Additionally, what *does* go into said area has tons of things that are only related by the kind of operation- not because they actually have anything to do with each other. This was one of the complaints levied at the approach for moving all the ACL checking into one place. I think it would be good to have a consistant naming/calling scheme for these various functions, but I'm not sure that moving them all to the same place makes sense. Thanks, Stephen
From: Tom Lane on 23 May 2010 11:10 Stephen Frost <sfrost(a)snowman.net> writes: > * Robert Haas (robertmhaas(a)gmail.com) wrote: >> Long story short, this is kind of a mess. > ... I think it would be good to have a > consistant naming/calling scheme for these various functions, but I'm > not sure that moving them all to the same place makes sense. 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. BTW, the plain-name cases should be "const char *", else some callers will have to cast away const. You could possibly make an argument for "const List *" in the qualified-name cases, but we don't do that anywhere else so I think it'd just look funny here (and would require internally casting away const, too). 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 11:19 On Sun, May 23, 2010 at 11:10 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Stephen Frost <sfrost(a)snowman.net> writes: >> * Robert Haas (robertmhaas(a)gmail.com) wrote: >>> Long story short, this is kind of a mess. > >> ... I think it would be good to have a >> consistant naming/calling scheme for these various functions, but I'm >> not sure that moving them all to the same place makes sense. > > 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? > BTW, the plain-name cases should be "const char *", else some callers > will have to cast away const. You could possibly make an argument for > "const List *" in the qualified-name cases, but we don't do that > anywhere else so I think it'd just look funny here (and would require > internally casting away const, too). Makes sense. -- 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 11:30 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. 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
|
Next
|
Last
Pages: 1 2 3 4 Prev: [HACKERS] mapping object names to role IDs Next: [PATCH] Move 'long long' check to c.h |