On 1/30/09, Merlin Moncure <mmoncure@gmail.com> wrote:
> On 1/29/09, Gregory Stark <stark@enterprisedb.com> wrote:
> >
> > I'm putting together a talk on "PostgreSQL Pet Peeves" for discussion at
> > FOSDEM 2009 this year. I have a pretty good idea what some them are of course,
>
>
> Here are couple of mine. Had to dig a bit. There may be some
> duplication with others:
>
> *) In place upgrade (everybody's #1)
> *) lack of *generally usable* standalone mode which leads to:
> *) libpq. needs rewrite: incorporate libpqtypes functionality, sane
> error system, many other things. would be nice to be able to use
> libpq in standalone as described above.
> *) update foo set foo = foo; doesn't work (currently thread on hackers)
> *) named parameters in plain sql functions don't work
> *) can't use insert/update returning in subquery (prob #3 requested
> after IPU and hot standy)
> *) stored procedures!! to some, this means multiset. to me, it means
> pl/pgsql without automatic transaction mgmt. ideally, we get both
> *) CTE expressions can't end in insert (slight variant of above)
> *) no easy way to have database feed constants into 'create replace
> function' would be nice to have above take string expression, not
> literal
> *) libpqtypes bumped to contrib :D
> *) would be nice to run some arbitrary sql when session dumps. only
> possible today with highly circuitous on_proc_exit that connects back
> to the database...ugh
> *) listen/notify needs reworking
> *) pl/sh should be raised to contrib at minimum. diamond in the rough
>
> and my #1 pet peeve is <drumroll>:
> *) having to answer questions about why count(*) is slow!
ooh, I forgot my number personal #1 peeve (and 1a) .
*) select (func()).* will execute func once per field in returned
record. This is side effect of
*) '*' being macro expanded into the plan. I've raised this a couple
of times in hackers. I don't know if there's a clean solution to this
behavior.
merlin