Re: [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

2016-03-11 22:08 GMT+01:00 Robert Haas <robertmhaas(at)gmail(dot)com>:

> On Fri, Mar 11, 2016 at 3:44 PM, Joel Jacobson <joel(at)trustly(dot)com> wrote:
> > On Fri, Mar 11, 2016 at 11:14 AM, Robert Haas <robertmhaas(at)gmail(dot)com>
> wrote:
> >> I'm not direly opposed to most of what's on that page,
> >> but I'm not excited about most of it, either.
> >
> > May I ask, what improvements of PL/pgSQL would you personally be most
> > excited about,
> > if you or someone else would have unlimited resources to hack on it?
> >
> >> I bet if we canvassed 10 different companies that made heavy use of
> PL/pgsql they'd all have
> >> a list of proposed changes like that, and I bet some of them would
> >> conflict with each other, and I bet if we did all that stuff the
> >> average PL/pgsql user's life would not be much better, but the manual
> >> would be much longer.
> >
> > You as a professional PostgreSQL consultant obviously have a lot of more
> > contact than me with other companies who make heavy use of PL/pgSQL.
> >
> > I'm assuming your bet on these proposed changes in conflict you talk
> about
> > are based on things you've picked up IRL from companies you've been
> > working with.
> >
> > What would you say are the top most commonly proposed changes
> > from companies that make heavy use of PL/pgSQL, and which of those are
> > in conflict?
>
> I don't think my experience in this area is as deep as you seem to
> think. I can tell you that most of the requests EnterpriseDB gets for
> PL/pgsql enhancements involve wanting it to be more like Oracle's
> PL/SQL, which of course has very little overlap with the stuff that
> you're interested in. But I'm not really commenting here based on
> that. I'm just giving you my impression based on the discussion I've
> seen on the mailing list and my own personal feelings. If there is an
> outcry for STRICT as you have proposed it, I'm not especially opposed
> to that. I just think it needs a consensus that I haven't seen
> emerge.
>

This proposal is not bad from my perspective - but in detail these points
breaks compatibility, can have negative performance impacts or are ugly. I
understand to all points, but I am not sure, if the benefits are better
than costs (compatibility issues).

Can we talk about these points in separate thread? I can imagine few points
as extra checks. This is probably theme for 9.6, so we can discuss about it
in 9.6 release cycle.

Regards

Pavel

>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>