Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
Big thank you!Big thank you!Posted Jan 19, 2005 22:35 UTC (Wed) by bojan (subscriber, #14302)Parent article: PostgreSQL 8.0.0 released
Thanks everyone that put effort into making PostgreSQL so good. You are doing a fabulous job!
(Log in to post comments)
Big thank you seconded! Posted Jan 19, 2005 23:51 UTC (Wed) by ccyoung (subscriber, #16340) [Link] great job! a real pleasure to work with this db.
minor notes:
not mentioned anywhere but supposedly there are session variables (dangerous but delicious).
added parameters to cursors.
vacuum sucks. they've made it into a lightweight process - now the final step is to make it simply an on-going, self-tuning part of pg itself. (as with analyze.)
still no autonomous transactions (sorry, personal favorite)
un-defaulted oids - what little objectness seems to be taking a backseat to mainstream sql issues.
nice formalization of function/transaction dependencies so they can be properly optimized (and written).
ms binary, although chewing gum in some people's eyes (eg, mine), a huge step in greater acceptance (compare Evolution to Firefox).
would love to see osd or apache take pg under its wings. with the little bit of money it's taken big strides, imho on the threshhold of the killer app.
Big thank you seconded! Posted Jan 20, 2005 1:02 UTC (Thu) by prasadgc (guest, #27375) [Link] ccyoung said:
> vacuum sucks.
isn't that what vacuum is expected to do? ;-)
Ganesh
Big thank you seconded! Posted Jan 20, 2005 21:00 UTC (Thu) by sbergman27 (subscriber, #10767) [Link] > vacuum sucks.
pg_autovacuum is included with the distribution and handles the vacuuming as needed, automatically.
Think of it as a sort of Roomba for your database.
Big thank you seconded! Posted Jan 21, 2005 1:01 UTC (Fri) by zblaxell (subscriber, #26385) [Link] "un-defaulted oids" - and good riddance, I say. I can finally stopwriting "without oids" except for the extremely rare occurrences where I actually want a table that can be inherited from. Man, that was annoying. ;-) Am I missing something, or is there very little useful about OO tables that can't be achieved with some rules and triggers on a conventional (or at least non-OO) database? Seems to me the OID does basically the same thing an integer sequence primary key does, except using built-in facilities instead of some views and insert/update/delete hooks. Does the back-end do some incredibly efficient organization of tables with an inheritance relationship, or is it just a legacy PostgreSQL-specific syntax for something that could now be implemented in plain SQL?
|
|||||||||||