PROCEDUREs *which compile into Procedure Cache* and have IN/OUT (Mode) parameters..
Martin Gainty ______________________________________________ Disclaimer and confidentiality note Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission. > Date: Fri, 30 Jan 2009 12:37:11 +0900 > From: cr...@postnewspapers.com.au > To: st...@enterprisedb.com > CC: pgsql-general@postgresql.org > Subject: Re: [GENERAL] Pet Peeves? > > Gregory Stark wrote: > > > So, what do people say? Is Postgres perfect in your world or does it do some > > things which rub you the wrong way? > > The few things that used to really bug me have gone away between 8.1 and > 8.3. The big one is that there are no longer issues with temp tables in > PL/PgSQL functions or any of the other problems related to the lack of > automatic plan invalidation for functions. > > I could go on forever about the things I LIKE about Pg. > > > There are a few niggles I have noticed, though: > > - VACUUM FULL is rather slow and often leaves indexes badly bloated. > This is a usability issue for new admins, too, who won't know they're > usually better off using CLUSTER. That in its self suggests something's > not right, IMO. > > - There's no REINDEX CONCURRENTLY. > > - There are no built-in ways for admins to easily discover, be alerted > to, or manually check for index and table bloat. We NEED a > pg_catalog.pg_bloat view IMO, as well as NOTICE level warnings from > VACUUM when very bloated indexes and tables are discovered. This is a > mainly a usability issue for new admins. > > - Bytea's literal format is wasteful and is painful to work with. > Supporting something reasonably compact and commonly understood by most > tools and libraries (like, say, base64) would be really nice. It'd also > be useful for backup/restore. > > - The problems involved in restoring/upgrading a database to a newer > major version when extensions like PostGIS are in use. Argh. > > - Table partitioning is effective, but somewhat clumsy, and would really > benefit from some automatic management tools. > > - No column-level triggers and, thus, no way to attach a trigger to a > domain type. > > - The need for a dump and restore for major version upgrades. I > understand why, but ... > > -- > Craig Ringer > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general _________________________________________________________________ Windows Live™ Hotmail®:…more than just e-mail. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t2_hm_justgotbetter_explore_012009
