Re: [HACKERS] How to give permission to others on data directory
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 again Regards Amit Khare - Original Message - From: Peter Eisentraut <[EMAIL PROTECTED]> To: Amit Khare <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Sunday, March 31, 2002 4:20 AM Subject: Re: [HACKERS] How to give permission to others on data directory > Amit Khare writes: > > > (1) Actually we are doing project on PostgreSQL in group of two. We installed individual copy of PostgreSQL into our group directory. > > (2) When I created data directory and ran "initdb" it makes me( takes my login name ) as the owner of data directory. > > (3) The problem is that now my partner cannot start the postmaster since he does not have right on the data directory. Further one cannot set right on the data directory more than 700 . > > (4) For time being we hacked the postmaster.c and commented the line starting from 318 which actually test the permission on data directory. Then my partner was able to run the postmaster since now I gave him rights(770) on the data directory(But changed rights on postgresql.conf file to 744). > > > > (5) Is there a clean way by which my partner can start postmaster on data directory created by me. > > Create a separate user for the server and give yourself and your partner > access to it. > > -- > Peter Eisentraut [EMAIL PROTECTED] > > > ---(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 > _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Data integrity and sanity check
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 otherwise. - Original Message - From: "Christopher Kings-Lynne" <[EMAIL PROTECTED]> To: "Rod Taylor" <[EMAIL PROTECTED]> Cc: "Ferruccio Zamuner" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Sunday, March 31, 2002 12:31 AM Subject: Re: [HACKERS] Data integrity and sanity check > > BTW. There are good reasons sometimes for having data that violates > > current constraints. The top of a tree may have a static record with > > a null parent. The NOT NULL constraint added after this entry (via > > alter table add constraint) should not affect the static record, so > > unless you know your data quite well this type of tool wouldn't be > > particularly useful anyway. > > As far as I am aware, there is no alter table add constraint syntax for > NOT NULLs atm. I've submitted a patch that allows alter table/alter > column set/drop not null though. > > Chris > > > > ---(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 > ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] How to give permission to others on data directory
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 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 again > > Regards > Amit Khare > - Original Message - > From: Peter Eisentraut <[EMAIL PROTECTED]> > To: Amit Khare <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Sunday, March 31, 2002 4:20 AM > Subject: Re: [HACKERS] How to give permission to others on data directory > > > Amit Khare writes: > > > (1) Actually we are doing project on PostgreSQL in group of two. We > > installed individual copy of PostgreSQL into our group directory. > > > > (2) When I created data directory and ran "initdb" it makes me( takes > > > my > > login name ) as the owner of data directory. > > > > (3) The problem is that now my partner cannot start the postmaster > > > since > > he does not have right on the data directory. Further one cannot set right > on the data directory more than 700 . > > > > (4) For time being we hacked the postmaster.c and commented the line > > starting from 318 which actually test the permission on data directory. > Then my partner was able to run the postmaster since now I gave him > rights(770) on the data directory(But changed rights on postgresql.conf > file to 744). > > > > (5) Is there a clean way by which my partner can start postmaster on > > data directory created by me. > > > Create a separate user for the server and give yourself and your partner > > access to it. > > > > -- > > Peter Eisentraut [EMAIL PROTECTED] > > > > > > ---(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 > > _ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster --- ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] RI triggers and schemas
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 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 ON "bar" FROM "baz" NOT DEFERRABLE
INITIALLY IMMEDIATE FOR EACH ROW EXECUTE PROCEDURE "RI_FKey_noaction_upd"
('', 'baz', 'bar', 'UNSPECIFIED', 'f1', 'f1');
which will absolutely not work at all if the 7.3 triggers are expecting
to find OIDs in those arguments.
I thought about allowing the triggers to take qualified names in the
style of what nextval() is doing in current sources, but that's still
going to have a lot of nasty compatibility issues --- mixed-case
names, names containing dots, etc are all going to be interpreted
differently than before.
I think we may have little choice except to create two sets of RI trigger
procedures, one that takes the old-style arguments and one that takes
new-style arguments. However the old-style set will be horribly fragile
because they'll have to interpret their arguments based on the current
namespace search path.
Of course the *real* problem here is that pg_dump is outputting a
low-level representation of the original constraints. We knew all along
that that would get us into trouble eventually ... and that trouble is
now upon us. We really need to fix pg_dump to emit ALTER TABLE ADD
CONSTRAINT type commands instead of trigger definitions.
A possible escape from the dilemma is to fix pg_dump so that it can emit
ADD CONSTRAINT commands when it sees RI triggers, release that in 7.2.2,
and then *require* people to use 7.2.2 or later pg_dump when it comes
time to update to 7.3. I do not much like this ... but it may be better
than the alternative of trying to maintain backwards-compatible
triggers.
Comments? Better ideas?
regards, tom lane
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] RI triggers and schemas
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 pg_upgrade script (any 7.2 release to 7.3)
That said, it doesn't look like it'll be a pretty thing to do with a
shell script.
Hoop jumping may be required to go from 6.5 or 7.0/1 directly to 7.3.
Downside is pg_upgrade is fairly new (can it be trusted -- made to
work 100%?)
Upside is no changes would be required to 7.2 and lots of people would
be really happy to have a fast upgrade process (dump / restore can
take quite a while on large dbs)
--
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
otherwise.
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
To: "Stephan Szabo" <[EMAIL PROTECTED]>
Cc: "Jan Wieck" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Sunday, March 31, 2002 8:43 PM
Subject: Re: [HACKERS] RI triggers and schemas
> 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 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 ON "bar" FROM
"baz" NOT DEFERRABLE INITIALLY IMMEDIATE FOR EACH ROW EXECUTE
PROCEDURE "RI_FKey_noaction_upd" ('', 'baz', 'bar',
'UNSPECIFIED', 'f1', 'f1');
>
> which will absolutely not work at all if the 7.3 triggers are
expecting
> to find OIDs in those arguments.
>
> I thought about allowing the triggers to take qualified names in the
> style of what nextval() is doing in current sources, but that's
still
> going to have a lot of nasty compatibility issues --- mixed-case
> names, names containing dots, etc are all going to be interpreted
> differently than before.
>
> I think we may have little choice except to create two sets of RI
trigger
> procedures, one that takes the old-style arguments and one that
takes
> new-style arguments. However the old-style set will be horribly
fragile
> because they'll have to interpret their arguments based on the
current
> namespace search path.
>
> Of course the *real* problem here is that pg_dump is outputting a
> low-level representation of the original constraints. We knew all
along
> that that would get us into trouble eventually ... and that trouble
is
> now upon us. We really need to fix pg_dump to emit ALTER TABLE ADD
> CONSTRAINT type commands instead of trigger definitions.
>
> A possible escape from the dilemma is to fix pg_dump so that it can
emit
> ADD CONSTRAINT commands when it sees RI triggers, release that in
7.2.2,
> and then *require* people to use 7.2.2 or later pg_dump when it
comes
> time to update to 7.3. I do not much like this ... but it may be
better
> than the alternative of trying to maintain backwards-compatible
> triggers.
>
> Comments? Better ideas?
>
> regards, tom lane
>
> ---(end of
broadcast)---
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] RI triggers and schemas
> 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 ON "bar" FROM "baz" NOT
>DEFERRABLE INITIALLY IMMEDIATE FOR EACH ROW EXECUTE PROCEDURE "RI_FKey_noaction_upd"
>('', 'baz', 'bar', 'UNSPECIFIED', 'f1', 'f1');
>
> which will absolutely not work at all if the 7.3 triggers are expecting
> to find OIDs in those arguments.
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...
Chris
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] RI triggers and schemas
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 are pretty durn ugly themselves. This ugliness would at least be localized. Might be a plan. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] RI triggers and schemas
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 ... seems pretty ugly, but then again the alternatives are pretty > durn ugly themselves. This ugliness would at least be localized. > Might be a plan. 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 that faster since right now it's just running the check on each row, but it'll still be slow on big tables possibly. Another option would be to have an argument that would disable the check on an add constraint, except that wouldn't work for unique/primary key. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] RI triggers and schemas
> 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 > that faster since right now it's just running the check on each row, > but it'll still be slow on big tables possibly. Another option would > be to have an argument that would disable the check on an add constraint, > except that wouldn't work for unique/primary key. Maybe it could be a really evil SET CONSTRAINTS command like: SET CONSTRAINTS UNCHECKED; ... Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] RI triggers and schemas
> 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 > that faster since right now it's just running the check on each row, > but it'll still be slow on big tables possibly. Another option would > be to have an argument that would disable the check on an add constraint, > except that wouldn't work for unique/primary key. Maybe it could be a really evil SET CONSTRAINTS command like: SET CONSTRAINTS UNCHECKED; ... Chris ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
