"user"

Forgott to say that I try to create a table named
<QUOTE>user</QUOTE>.

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

"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

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
--------------------------------

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!