Thread: TODO updates

TODO updates

From
Peter Eisentraut
Date:
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



Re: TODO updates

From
Philip Warner
Date:
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   |/


Re: TODO updates

From
Tom Lane
Date:
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


Re: TODO updates

From
Tom Lane
Date:
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


Re: TODO updates

From
Philip Warner
Date:
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   |/


Re: TODO updates

From
Tom Lane
Date:
>> 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


Re: TODO updates

From
Philip Warner
Date:
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   |/


Re: TODO updates

From
Tom Lane
Date:
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


Re: TODO updates

From
Philip Warner
Date:
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   |/


Re: TODO updates

From
Philip Warner
Date:
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   |/


Re: TODO updates

From
Karel Zak
Date:
> 
> * -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. :-) 



Re: TODO updates

From
Bruce Momjian
Date:
[ 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
 


Re: TODO updates

From
Bruce Momjian
Date:
> 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
 


Re: TODO updates

From
Bruce Momjian
Date:
> 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