Re: [SQL] why don't this create table work?

User & <marc(at)oscar(dot)noc(dot)cv(dot)net> writes:
> nnm=> create table nnm_event_limits (
> nnm-> nodename varchar(256) not null,
> nnm-> event_oid varchar(256) not null,
> nnm-> always_never varchar(1) null,
> nnm-> limit int4);
> ERROR: parser: parse error at or near "null"

> This is converted from openviews table scheema.

Openviews is allowing stuff that is not in the SQL92 spec --- AFAICS
there is nothing in the spec about a "NULL" column qualification.
You can say "NOT NULL" or you can leave it out.

> limit is not a reserved word as far as I can tell, any ideas?

Yes it is. Probably we could allow it as a column name anyway,
but it's not listed as a "safe" column ID in the 6.5 grammar.
If you're determined to use it as a column name even though it's
reserved, put double quotes around it, eg "limit" int4. But you'll
have to do that every time you refer to it in a query, so choosing
another name is probably the path of least resistance.

> ps would useing text instead of varchar be a good thing to do?

Use varchar if you have an application-defined reason to want to
enforce a specific upper limit on the length of the string in
a column. If you don't have any particular upper limit in mind,
use text --- it's the same thing as varchar except for the limit.

In the above example, I'll bet a nickel that you have no clear reason
for specifying an upper limit of 256 on nodename and event_oid, so they
should probably be text. If always_never can legitimately be either 0
or 1 chars long, but never more, then varchar(1) is the right
declaration. (Perhaps it should always be 1 char long --- in that case
you should've said char(1). Note that NULL is by no means the same
thing as a zero-character string.)

regards, tom lane