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...

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 |/

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

Peter Eisentraut <peter_e@gmx.net> writes:

Meanwhile a few TODO updates:

* Creating index of TIMESTAMP & RELTIME fails, or rename to DATETIME(Thomas)

Looks obsolete to me. (Reltime indexes still don't work, but I doubt
someone needs them.)

Hm. It looks like the following standard types are not indexable
(or at least don't have default opclass entries) in current sources:

aclitem
bit
bytea
cid
filename
int2vector
line
lseg
money
path
point
regproc
reltime
smgr
tid
tinterval
varbit
xid

There are three more that are indexable but not by btree (we only
have rtree support, which I guess makes sense here):

box
circle
polygon

It surprises me that we don't have index support for reltime and
tinterval (I think only a 3-way comparison proc and a few table entries
are missing). regproc is even closer, it just needs table entries.
bit/varbit are of course just Not There Yet (but I see comparison
functions exist --- just the AM table entries don't.)

Another notable omission is that there should be rtree support for all
the geometric types (what happened to line, lseg, path, point?)

Lack of indexability of these other types doesn't bother me much.

So I guess an up-to-date version of this TODO item should read

* Add btree index support for reltime, tinterval, regproc, bit, varbit
* Add rtree index support for line, lseg, path, point

* Add hash for int8

Seems to work (Tom Lane?)

Yeah, I fixed that a month ago.

See y'all in beta... :-)

Have a good one...

regards, tom lane

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 |/

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

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 |/

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

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 |/

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 |/

* -More access control over who can create tables and use locks(Karal)

Not done, and it's "Karel".

My old patch for this is usable, but as we already discussed about it,
more "systematic" solution is overwrite a ACL. In this context I not sure
if my name is right here. I can help with this because I need this features
for some my private projects, but now I don't want work on more projects if
the query cache is still open (and still is a quiet about it! (look at
anyone my first snapshot?)).

Plan anyone (Peter?) ACL at eyeshot time?

Karel

PS. "Karel" = "Charles" in Eng. :-)

[ Charset ISO-8859-1 unsupported, converting... ]

I'm going to be on vacation for essentially the next month. So if there's
anything that you'd like fixed before that, now's a good time to tell.

Meanwhile a few TODO updates:

* Creating index of TIMESTAMP & RELTIME fails, or rename to DATETIME(Thomas)

Looks obsolete to me. (Reltime indexes still don't work, but I doubt
someone needs them.)

Marked as done.

* -More access control over who can create tables and use locks(Karal)

Not done, and it's "Karel".

Sorry, fixed.

* Test syslog functionality
* Unify configuration into one configuration file (Peter E)
* use setproctitle() if it exists for 'ps' display of status

All done

Yes.

* Add hash for int8

Seems to work (Tom Lane?)

Yes.

* BSD/OS does not support locale because there is no LC_MESSAGES

Done

Yes.

* Add ALTER TABLE DROP/ALTER COLUMN feature(Peter E) [drop]

`ALTER TABLE ALTER COLUMN' was implemented for 7.0. I am not working on
the DROP COLUMN part, so you might want to remove my name.

Entry split into two lines and updated.

* Allow DELETE and UPDATE to use inheritance using tablename*

Chris Bitmead's contributions accomplish that (though not how it's written
here).

Fixed, with tablename* removed.

There seem to be some duplicate items:

* Some database schema's are not dumpable; do dumps in oid order
* make pg_dump dump in oid order, so dependencies are resolved

* Allow nulls in arrays
* Allow arrays to hold NULL elements

Duplicates removed.

-- 
  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

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

Lack of indexability of these other types doesn't bother me much.

So I guess an up-to-date version of this TODO item should read

* Add btree index support for reltime, tinterval, regproc, bit, varbit
* Add rtree index support for line, lseg, path, point

TODO updated.

* Add hash for int8

Seems to work (Tom Lane?)

Yeah, I fixed that a month ago.

TODO updated.

-- 
  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