At 14:58 23/07/00 +0200, Peter Eisentraut wrote:
>
>* Some database schema's are not dumpable;  do dumps in oid order
>* make pg_dump dump in oid order, so dependencies are resolved
>

As of the latest pg_dump, it dumps in modified oid order: rules, triggers,
views and indexes always go at end, but the rest is in oid order. If people
want a strict oid order, then it's a matter of commenting out 4 or 5 lines...

Does this mean I've actually done a ToDo item? I was trying to limit myself
to useless features that noone wants...



----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.C.N. 008 659 498)             |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|
                                 |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/

Sun, 23 Jul 2000 23:11:12 +1000
Philip Warner <pjw@rhyme.com.au>
Re: TODO updates
Philip Warner <pjw@rhyme.com.au> writes:
> As of the latest pg_dump, it dumps in modified oid order: rules, triggers,
> views and indexes always go at end, but the rest is in oid order.

Hmm, I think you need to dump views in OID order just as though they
were tables.  What if an SQL function refers to a view?

Those other categories seem safe to handle this way, though.

			regards, tom lane

Sun, 23 Jul 2000 12:36:25 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: TODO updates 
At 12:36 23/07/00 -0400, Tom Lane wrote:
>Philip Warner <pjw@rhyme.com.au> writes:
>> As of the latest pg_dump, it dumps in modified oid order: rules, triggers,
>> views and indexes always go at end, but the rest is in oid order.
>
>Hmm, I think you need to dump views in OID order just as though they
>were tables.  What if an SQL function refers to a view?

The actual list of things it moves to the end is: TABLE DATA, BLOBS, INDEX,
TRIGGER, RULE and ACL. The underlying table for a view is created in OID
order, so I would guess that referencing it in an SQL function would still
be OK. Is that OK?




----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.C.N. 008 659 498)             |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|
                                 |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/

Mon, 24 Jul 2000 10:50:07 +1000
Philip Warner <pjw@rhyme.com.au>
Re: TODO updates 
>> Philip Warner <pjw@rhyme.com.au> writes:
>>> As of the latest pg_dump, it dumps in modified oid order: rules, triggers,
>>> views and indexes always go at end, but the rest is in oid order.
>> 
>> Hmm, I think you need to dump views in OID order just as though they
>> were tables.  What if an SQL function refers to a view?

> The actual list of things it moves to the end is: TABLE DATA, BLOBS, INDEX,
> TRIGGER, RULE and ACL. The underlying table for a view is created in OID
> order, so I would guess that referencing it in an SQL function would still
> be OK. Is that OK?

Oh, I see, you're emitting the underlying table and the rule separately.
Yeah, I think that will probably work.

Is it safe to postpone ACL setting?  Less sure about that ... I think
the rule parser checks ACLs at parse time instead of execution, for
example.

			regards, tom lane

Sun, 23 Jul 2000 23:27:59 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: TODO updates 
At 23:27 23/07/00 -0400, Tom Lane wrote:
>
>> The actual list of things it moves to the end is: TABLE DATA, BLOBS, INDEX,
>> TRIGGER, RULE and ACL. The underlying table for a view is created in OID
>> order, so I would guess that referencing it in an SQL function would still
>> be OK. Is that OK?
>
>Oh, I see, you're emitting the underlying table and the rule separately.
>Yeah, I think that will probably work.

This one bothers me a little actually; I would prefer if it output a valid
'Create View' statement, in which case it would have to go in OID order.
Where possible, I want the output to be vanilla SQL, but I probably won't
do it yet.


>Is it safe to postpone ACL setting?  Less sure about that ... I think
>the rule parser checks ACLs at parse time instead of execution, for
>example.

Well, the theory I was working on was that it was possible that the ACLs
would deny the current user access to parts of the database, so I put them
at the end. 

Do you mean that by putting the ACLs at the end I may be allowing access
(via the rule parser) that is inappropriate?


----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.C.N. 008 659 498)             |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|
                                 |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/

Mon, 24 Jul 2000 13:35:13 +1000
Philip Warner <pjw@rhyme.com.au>
Re: TODO updates 
Philip Warner <pjw@rhyme.com.au> writes:
> Do you mean that by putting the ACLs at the end I may be allowing access
> (via the rule parser) that is inappropriate?

I'm more worried about failing to allow access that's necessary to do
the restore.  What about

\connect - user1

create table t1;

\connect - user2

create rule .... (refers to t1)

I think the create rule will fail if you haven't yet granted user2
access rights for t1.

			regards, tom lane

Sun, 23 Jul 2000 23:50:13 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: TODO updates 
At 23:50 23/07/00 -0400, Tom Lane wrote:
>
>I'm more worried about failing to allow access that's necessary to do
>the restore.  What about
>
>\connect - user1
>
>create table t1;
>
>\connect - user2
>
>create rule .... (refers to t1)
>
>I think the create rule will fail if you haven't yet granted user2
>access rights for t1.
>

You are right; and I just noticed two bugs in pg_dump - (1) it does not
dump the owner of a view (which means the ACLs still might fail), and (2)
it does not reconnect to DB when using a direct DB connection, so
everything is created by one user.

So, I'll put the ACLs in OID order and fix the dump & restore code...


----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.C.N. 008 659 498)             |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|
                                 |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/

Mon, 24 Jul 2000 14:05:37 +1000
Philip Warner <pjw@rhyme.com.au>
Re: TODO updates 
At 14:05 24/07/00 +1000, Philip Warner wrote:
>At 23:50 23/07/00 -0400, Tom Lane wrote:
>>
>>I'm more worried about failing to allow access that's necessary to do
>>the restore.  What about
>>
>>\connect - user1
>>
>>create table t1;
>>
>>\connect - user2
>>
>>create rule .... (refers to t1)
>>
>>I think the create rule will fail if you haven't yet granted user2
>>access rights for t1.
>>
>
>You are right; and I just noticed two bugs in pg_dump - (1) it does not
>dump the owner of a view (which means the ACLs still might fail), and (2)
>it does not reconnect to DB when using a direct DB connection, so
>everything is created by one user.
>
>So, I'll put the ACLs in OID order and fix the dump & restore code...
>

Done, tested & applied.


----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.C.N. 008 659 498)             |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|
                                 |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/

Mon, 24 Jul 2000 16:33:26 +1000
Philip Warner <pjw@rhyme.com.au>
Re: TODO updates 
> At 14:58 23/07/00 +0200, Peter Eisentraut wrote:
> >
> >* Some database schema's are not dumpable;  do dumps in oid order
> >* make pg_dump dump in oid order, so dependencies are resolved
> >
> 
> As of the latest pg_dump, it dumps in modified oid order: rules, triggers,
> views and indexes always go at end, but the rest is in oid order. If people
> want a strict oid order, then it's a matter of commenting out 4 or 5 lines...

TODO updated, and you are listed in there now.

> 
> Does this mean I've actually done a ToDo item? I was trying to limit myself
> to useless features that noone wants...

:-)

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Thu, 27 Jul 2000 14:49:44 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: TODO updates