Обсуждение: TODO updates
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.) * -More access control over who can create tables and use locks(Karal) Not done, and it's "Karel". * Test syslog functionality * Unify configuration into one configuration file (Peter E) * use setproctitle() if it exists for 'ps' display of status All done * Add hash for int8 Seems to work (Tom Lane?) * BSD/OS does not support locale because there is no LC_MESSAGES Done * 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. * Allow DELETE and UPDATE to use inheritance using tablename* Chris Bitmead's contributions accomplish that (though not how it's written here). 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 See y'all in beta... :-) -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
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:
aclitembitbyteacidfilenameint2vectorlinelsegmoneypathpointregprocreltimesmgrtidtintervalvarbitxid
There are three more that are indexable but not by btree (we only
have rtree support, which I guess makes sense here):
boxcirclepolygon
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
thiscontext I not sureif my name is right here. I can help with this because I need this featuresfor 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!
(lookat 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, Pennsylvania19026
> 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, Pennsylvania19026
> 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, Pennsylvania19026