Hi Peter,
Thank you very much for your reply .
However the problem is that we don't want to create separate user for
server. If initdb takes my login name and makes me owner of the data
directory then how should I be able to give permission to other users in
this case my project partner?
Thanks
There was -- kinda
alter table tab add constraint check (value not null);
--
Rod Taylor
Your eyes are weary from staring at the CRT. You feel sleepy. Notice
how restful it is to watch the cursor blink. Close your eyes. The
opinions stated above are yours. You cannot imagine why you ever felt
Create a separate user and both of you use sudo to start the database.
If you're insistent on keeping yourself owner of the data then use sudo to
give permission to your project partner to start the database.
On Sunday 31 March 2002 05:49 am, Amit Khare wrote:
Hi Peter,
Thank you very much for
Last week I said:
I think that instead of storing just table names in the trigger
parameters, we should store either table OIDs or schema name + table
name. [ ... ]
So I'm leaning towards OIDs, but wanted to see if anyone had a beef
with that.
I've just realized that if we change the RI
If pg_upgrade was shipped with 7.3 in working order with the ability
to convert the old foreign key commands to the new ones I don't think
anyone would care how many funny things are involved. Just fix the
foreign key stuff for 7.3 pg_dump and only support upgrades using that
version, or
I've just realized that if we change the RI trigger arguments this way,
we will have a really serious problem with accepting pg_dump scripts
from prior versions. The scripts' representation of foreign key
constraints will contain commands like
CREATE CONSTRAINT TRIGGER unnamed AFTER UPDATE
Yeah, although it'd still be a good idea probably to convert the dump form
to ALTER TABLE in any case. The one downside that was brought up in the
past was the time involved in checking dumped (presumably correct) data
when the constraint is added to very large tables. I can probably make
Yeah, although it'd still be a good idea probably to convert the dump form
to ALTER TABLE in any case. The one downside that was brought up in the
past was the time involved in checking dumped (presumably correct) data
when the constraint is added to very large tables. I can probably make
