> 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 mak
> 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 mak
On Sun, 31 Mar 2002, Tom Lane wrote:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > Why can't we just hack up the CREATE CONSTRAINT TRIGGER code to look up
> > the OIDs, etc. for the arguments and convert them internally to an ALTER
> > TABLE/ADD CONSTRAINT or whatever...
>
> Hmm ... s
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Why can't we just hack up the CREATE CONSTRAINT TRIGGER code to look up
> the OIDs, etc. for the arguments and convert them internally to an ALTER
> TABLE/ADD CONSTRAINT or whatever...
Hmm ... seems pretty ugly, but then again the alternatives
> 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 "" AFTER UPDATE
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 included
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
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 fo
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
oth
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
10 matches
Mail list logo
