Skip site navigation (1) Skip section navigation (2)

Re: Pet Peeves?

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Pet Peeves?
Date: 2009-01-30 20:32:45
Message-ID: b42b73150901301232o40f6badp8612dcca2f49ce62@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-general
On 1/30/09, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> On 1/29/09, Gregory Stark <stark(at)enterprisedb(dot)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

In response to

Responses

pgsql-general by date

Next:From: Bruce MomjianDate: 2009-01-30 20:32:50
Subject: Re: Pet Peeves?
Previous:From: ries van TwiskDate: 2009-01-30 20:21:34
Subject: Re: PGSQL or other DB?

Privacy Policy | About PostgreSQL
Copyright © 1996-2013 The PostgreSQL Global Development Group