Re: [HACKERS] Raising funds for PostgreSQL

At 02:57 PM 12/6/99 -0700, Kyle Bateman wrote:

*>  - Allow a view of a union
*>  - Get rid of size restrictions on tuples (8K?)
*>  - Get rid of size restrictions on queries (16K)>  - Resident functions that can execute with super-privileges>
Thiswould mean that a PL function could execute as the user who created>    it (or perhaps some other user the database
creatermight specify).
 
This>    would allow certain information to come from a table that the calling
user>    might not normally have access to (without having access to the whole
table).
*>  - Support for outer (and other kinds of) joins>  - Column based permissions (I don't know if there are SQL
standardsfor
 
this)>  - Support for passwords in the TCL interface (is it there now?)
*> - Could a subquery be included in the target list of a query>    select a,(select b from c) from d where e = f;
>     (Not sure if this one is even standard SQL.)
*>  - Support for "alter table drop column"

While I don't have any money to offer, I just thought I'd point out
that each of the starred items are things that I've run into while
porting an application from Oracle in just the past three days.

The system builds and allows the editing of tables via a web
interface, and not being able to drop columns is a drag.  I'm
emulating it by renaming such columns to something invisible
(the user doesn't see the actual table, just what the application
thinks is in the table, so I just make it lie to the user after
the renaming), which for this particular application will be
acceptable for now.

Outer joins can be worked around, but at times it's painful,
though I'm finding that for this application at least at times
I can rewrite the query and make it more readable and efficient
without the outer join.  Apparently, outer joins are a temptation
for misuse.  But there are times when they're really helpful.

Allowing a view of a union can always be worked around in some
sort of brute-force manner but can require studying the
queries on it closely in order to properly rewrite them without
the view.

Tuple size restrictions coupled with the fact that LOBs aren't
dumped are also painful.  If 7.0 contains a "real" backup, will
it be able to backup LOBs?  That would help me in the port of
this application.

As the word gets out that Postgres has greatly improved in the
recent past, more and more folks will be looking to move stuff
over from commercial databases.  This is partly driven by the
web (entirely, in my case) where databases are extremely 
useful creatures, serving as the site's foundation in many
cases.  Oracle's pricing for web use is scandalous ($22K-ish
for a fully-paid up unsupported license on a PIII 500!) and
besides is overkill for all but the largest and busiest sites.
Postgres can fill a very important niche in this environment.
One that some folks think MySQL fills but, hey, I ain't trusting
any money transactions to a non-transactional database!

The focus on things like reliability and performance is 
extremely important, of course - MVCC in 6.5.*, a very
noticable decline in memory leaks ("drastic" is not too
strong a word), removing the uneccessary write to pg_log
after read-only selects were crucial for my own web-based
application.  WAL and a good backup facility are really
nice to think about for those of us who worry about our
hardware's reliability, and referential integrity constraints
for those of us who worry about our ability to write
bug-free code (I can't wait to play with Jan's new updates),
all very good things.

But Postgres is maturing to the point where users can point
to the reliability and performance aspects of the tool and
find little to complain about.  Now folks are going to start
concentrating on SQL language features more exclusively :)



- Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert
Serviceand other goodies at http://donb.photo.net.