Thread: "user"
Why is this so very commonly used word reserved? Is that some kind of #define so you easily can recompile PostgreSQL? If so, please guide me to the place. This is truly annoying. Thanks! Daniel Åkerud
Forgott to say that I try to create a table named <QUOTE>user</QUOTE>. > Why is this so very commonly used word reserved? > Is that some kind of #define so you easily can recompile > PostgreSQL? If so, please guide me to the place. This is > truly annoying. > > Thanks! > > Daniel Åkerud >
Daniel ?erud writes: > Why is this so very commonly used word reserved? Because SQL says so. More specifically, because USER is a special function. > Is that some kind of #define so you easily can recompile > PostgreSQL? Surely not. > If so, please guide me to the place. You can hack around in src/backend/parser/gram.y, remove the USER expansion of the c_expr nonterminal, and move the USER expansion of ColLabel up to TokenId. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
> Forgott to say that I try to create a table named > <QUOTE>user</QUOTE>. > > > Why is this so very commonly used word reserved? > > Is that some kind of #define so you easily can recompile > > PostgreSQL? If so, please guide me to the place. This is > > truly annoying. Rather than trying to tear apart a database system that was carefully designed with "user" as a word with meaning to the system, is there any reason why you can't use a slightly different name for your table? I tried the same thing once, by the way, and when I realized I couldn't name my table "user", I called it "users" - after all, there will be more than one user! :-) Other ideas are "usr", "db_user" (replace "db" with something meaningful to you), "user_info", etc. Just a thought. -------------------------------- Karen Ellrick S & C Technology, Inc. 1-21-35 Kusatsu-shinmachi Hiroshima 733-0834 Japan (from U.S. 011-81, from Japan 0) 82-293-2838 --------------------------------
> > Forgott to say that I try to create a table named > > <QUOTE>user</QUOTE>. > > > > > Why is this so very commonly used word reserved? > > > Is that some kind of #define so you easily can recompile > > > PostgreSQL? If so, please guide me to the place. This is > > > truly annoying. > > Rather than trying to tear apart a database system that was carefully > designed with "user" as a word with meaning to the system, is there any > reason why you can't use a slightly different name for your table? I tried > the same thing once, by the way, and when I realized I couldn't name my > table "user", I called it "users" - after all, there will be more than one > user! :-) Other ideas are "usr", "db_user" (replace "db" with something > meaningful to you), "user_info", etc. > > Just a thought. What I just can't understand is that I want to create a _table_ named "user", and I can't do that because there is a _function_ named exactly that. Why I care is becuase I'm kind of a perfectionist. I want the database to match the UML class diagram. Anyway I called it "uzer" now. Maybe usr is better... users is out of the question since table names are supposed to go in singularis. Thanks for the input though, all of you :) Daniel Åkerud
> What I just can't understand is that I want to create a _table_ named > "user", and I can't do that because there is > a _function_ named exactly that. I don't know about functions, but there is a basic concept in pgsql (possibly in SQL itself) called a user. "CREATE USER username [WITH [SYSID uid] ..." etc. Unless you always access your database with the user you originally used to create it, you have used the above command and others like it, so that you can then grant privileges to those users. > Why I care is becuase I'm kind of a > perfectionist. I want the database to match the UML class diagram. I can relate - I have had similar urges in other situations and had to bend. Maybe you could add a uniform prefix or suffix to all the table names (e.g. tbl_user), so that each table name minus the prefix matches the class diagram (I don't know what UML stands for, so if this is a silly comment, ignore me!). Probably too late though - you've probably made most of your structure by now. > Anyway I called it "uzer" now. Maybe usr is better... users is out of the > question since table names are supposed to go in singularis. Oh, I didn't know there were conventions for table names - I've probably been breaking them left, right, and sideways! But since my databases are only for my company's internal use (and you can see from the fact that my email address's username has a hyphen that my company, and other Japanese companies also, don't care much about conventions :-o), maybe it's okay... But for the future, does anybody know if there is a document out there that outlines the generally accepted conventions for SQL tables, columns, etc.? -------------------------------- Karen Ellrick S & C Technology, Inc. 1-21-35 Kusatsu-shinmachi Hiroshima 733-0834 Japan (from U.S. 011-81, from Japan 0) 82-293-2838 --------------------------------
"Daniel �kerud" <zilch@home.se> wrote in message news:007101c13b96$834e8960$c901a8c0@automatic100... > > Anyway I called it "uzer" now. Maybe usr is better... users is out of the > question since table names are supposed to go in singularis. Since a table is a collection of things, plural always seemed to make more sense to me. But I've seen it done both ways. Postgres system tables are singular, but it SqlServer, they're plural. What do other people think? Marshall
Marshall Spight wrote:
> "Daniel Åkerud" <zilch@home.se> wrote in message
> news:007101c13b96$834e8960$c901a8c0@automatic100...
> >
> > Anyway I called it "uzer" now. Maybe usr is better... users is out of the
> > question since table names are supposed to go in singularis.
>
> Since a table is a collection of things, plural always seemed to make
> more sense to me. But I've seen it done both ways. Postgres system
> tables are singular, but it SqlServer, they're plural.
>
> What do other people think?
hmm -- here's what we do. with postgresql 7.1, we use
static lookups: PLURALS
states.*
colors.*
types.*
stages.*
codes.*
(the collection of records -- plural -- in these tables
define and restrict what options are available for certain
contexts.)
fluctuating data: SINGULARS
client.*
contact.*
property.*
image.*
message.*
(each record -- singular -- in these tables represents a
significant thing that's of direct importance to our bottom
line.)
plus, the actual tables (which are prefixed with "_") are hidden
by the views (sans leading "_") we use to access them:
create TABLE _cust ( ... );
create VIEW cust AS SELECT ... FROM _cust ...;
create TABLE _contact ( ... );
create VIEW client AS SELECT ... FROM _cust,_contact WHERE ...;
create RULE add_client AS ON INSERT TO client DO INSTEAD ...;
create RULE upd_client AS ON UPDATE TO client DO INSTEAD ...;
and for joining via serial indexes, we use "ID":
create table _colors (
id SERIAL,
...
);
create table _stages (
id SERIAL,
...
);
create table _gizmo (
...
colors_id INTEGER REFERENCES _colors( id ),
stages_id INTEGER REFERENCES _stages( id ),
...
);
so that any field <something>_id references _<something>.id (we
can't use natural joins, but that's not a big deal with us.)
alas, there is a weakness here: if there's more than one instance
of a particular subtable: colors_id might need to be
interior_colors_id and exterior_colors_id. zut alors!
for name collisions, we improvise: instead of "user" we use "who"
(after considering, and rejecting, "human" "person" "someone"
and "creature") for example.
so, what pre-existing standards are there, Out There in Database
Land? and what problems can you postgresql fans find with this
paradigm? (it's worked pretty well for us so far... :)
--
They don't remember whether or not they weren't doing anything
I didn't want them to do.
-- Karen, on why she feeds the cats when they misbehave
will@serensoft.com
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!