Thread: [HACKERS] Open 6.3 issues (fwd)

Here are the items.  Can I remove any of them?

Looking over the list, the only major one I see is that pg_user is not
world-readable, and with Todd not responding, I am thinking I may need
to do some ripout.  Right now, \d does not work for non-super-users.
Can you imagine the problem reports we will get on that?

Many of these items can be moved to the TODO list after the release.

---------------------------------------------------------------------------

ORDER BY NULLs problem?
pg_user not world-readable, no initdb password option(Todd Brandys)
make psql \d optionally user pg_user(Bruce)
optimizer memory exhaustion with many OR's
max tuple size patch(Darren)
Is GROUP BY duplicates fixed?
Do we have a self-join optimizer performance problem?
Get interfaces fixed for new protocol
Profiling improvements?
Do we have a problem with GROUP BY without ORDER BY?
Problem with tables >2Gb
Do we want to add timestamps to elog messages?
ScanKeyData missing initializations
Can we improve vacuum locking issues?
Alpha/64-bit issues, mkoidname() problem
'Can not write block blind' error on createdb and regression collision
Views on aggregates fail
large objects memory exhaustion
subselect issues, NOT IN (empty query)
Commit sgml document sources(Thomas)
Commit html documents(Thomas)
Commit postscript documents(Thomas)
Fix isinf.c irix port problem reported by Andrew(Marc)
Check triggers regression test(Vadim)
Check select_views regression test
Test ecpg new struct features(Michael)
Test big-endian/little-endian operation(Tatsuo?)?
Linux library issues?



--
Bruce Momjian
maillist@candle.pha.pa.us

On Wed, 18 Feb 1998, Bruce Momjian wrote:

> Here are the items.  Can I remove any of them?
>
> Looking over the list, the only major one I see is that pg_user is not
> world-readable, and with Todd not responding, I am thinking I may need
> to do some ripout.  Right now, \d does not work for non-super-users.
> Can you imagine the problem reports we will get on that?

Okay, I just grabbed our "resident Oracle guru"s time to see how Oracle
does this, and I'm CCng him in on this...

Basically, from what we can tell, there is one large table that contains
the user information, including passwords.  If we go in as 'the dba'
himself (same as our super user), we can view the table in its
entirety...if we go in as "joe blow user", you can only look at a "view"
of the table.

"select * from all_users;" <- no passwords
"select * from dba_users;" <- includes passwords

So, I think that Todd has the right idea, but where we are lacking is the
ability to have pg_users "closed" to non-su users to view all its data,
but have it "open" through a system view...

So, what we need is the ability to have a view created, as part of the
system itself, that does:

"select usename,usesysid,<etc, minus passwd,valuntil>
 from pg_user;"

So that that information is available, but the password isn't...

> Here are the items.  Can I remove any of them?
>
> Get interfaces fixed for new protocol

We should call these out individually...

> Do we want to add timestamps to elog messages?

One of Massimo's patches did this. Should someone apply it? Won't be me
though. Also, will affect many regression tests so someone would have to go
through those...

> 'Can not write block blind' error on createdb and regression collision

This is a show-stopper...

> Commit sgml document sources(Thomas)
> Commit html documents(Thomas)
> Commit postscript documents(Thomas)

Will start on final doc formatting tonight; have a small section to write to
summarize the docs. Also, will need to redraw the figures since
bitmap->Applix->bitmap looks bad, and resizing makes it worse.

> Check select_views regression test

imo, all regression discrepencies are show-stoppers. This must be done, and if
noone else picks it up I will try to get to it. All it needs is for someone to
go through that test and verify that the new results are valid equivalent
reorderings of the old results (it's possible that the behavior of the
geometry operators has changed for the better, so that the new results are
better too). The byte count of the files is the same, and on first glance the
results are equivalent. But, someone should check more carefully.

> Linux library issues?

It appears that glibc2.0.7 will fix the problem. Andrew has updated the Linux
FAQ.

Thomas G. Lockhart wrote:
>
>
> > 'Can not write block blind' error on createdb and regression collision
>
> This is a show-stopper...

I'll take a look...

>
> > Check select_views regression test

Imho, it's better to get rid of second query from select_views.sql:

SELECT * FROM iexit ORDER BY 1, 2;
                                ^
2-nd attr is of path type, '<' for path-es compares # of path' points,
there are many 2,3,-points pathes there, ordering is valid but we
can't get the same results on different platforms/-S XXX.

Another way is replace the query with:

SELECT name, #thepath FROM iexit ORDER BY 1, 2;
             ^^^^^^^^ path_npoints()

Vadim