Re: [GENERAL] Re: ALTER TABLE ADD CONSTRAINT

[Jeff Daugherty]

>> Also, I see that alter table add constraint does not work for defaults.
>> 
>> Is this something that is going to be added?
> 
> That I do hope will be added since the only way to replicate the
> functionality is to drop, readd and repopulate a table.
> 
> Greg

I am not sure specifically what you are looking for but you can add a 
default value to a column in an ALTER TABLE statement:

ALTER TABLE two ALTER COLUMN col_b SET DEFAULT 1;

Beyond that you can use another ALTER statement to add a Foreign Key 
constraint to the column:

ALTER TABLE two ADD CONSTRAINT two_fk foreign key(col_b) REFERENCES 
tbl_one(col_a) match full;

The biggest thing that I have noticed is many things require you to use 
separate ALTER statements in order for them to work.

I hope this helps.

jeff


Jeff Daugherty
Database Systems Engineer
Great Bridge, LLC


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [GENERAL] very odd behavior

[Jeff Daugherty]

desc is a reserved word (descending, ascending, having,  from, etc...),
as in:
select * from foo order by col_a desc;
That is why you need the double quotes.
jeff



Jeff Daugherty
Database Systems Engineer
Great Bridge LLC

[EMAIL PROTECTED] wrote:

> I have 7.1
> 
> Can someone take a look the following
> and tell me why I'm getting errors?
> I'm completely baffled!
> 
> 
> what=> create table bla(desc text,def text,data text);
> ERROR:  parser: parse error at or near "desc"
> what=> create table bla("desc" text,def text,data text);
> CREATE
> what=>
> 
> ---(end of broadcast)---
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])


---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://www.postgresql.org/search.mpl

Re: [GENERAL] more-than-one-SERIAL column per table

[Jeff Daugherty]

I see no reason why a second SERIAL column would be needed.  As in the 
example for creating tbl_c, when you have a SERIAL as a primary  key, 
the foreign keys that reference it should be int4 not SERIAL.
jeff


Jeff Daugherty
Database Systems Engineer
Great Bridge LLC

will trillich wrote:

> On Sun, May 06, 2001 at 02:59:31AM +0200, Morten Primdahl wrote:
> 
>>> \d tbl_c_id_seq
>>> 
>>> if it is not there, you can create it yourself
>> 
>> Thanks, the sequence was not there. Just puzzled me that
>> when creating tbl_c, I get:
>> 
>> test=# CREATE TABLE tbl_c 
>>  (id SERIAL PRIMARY KEY,
>>   data VARCHAR(50),
>>   a SERIAL CONSTRAINT a_ref REFERENCES tbl_a(id),
>>   b SERIAL CONSTRAINT b_ref REFERENCES tbl_b(id)
>> );
> 
> 
> is there any paradigm wherein TWO serial values for one table
> might possible be useful? (since serial is really "int default
> nextval('sequence_seq')" how can the second serial be anything
> but redundant?)


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])