2017-05-03 18:54 GMT+02:00 David Fetter <da...@fetter.org>:
> On Wed, May 03, 2017 at 01:27:38PM -0300, Claudio Freire wrote:
> > On Wed, May 3, 2017 at 11:31 AM, David Fetter <da...@fetter.org> wrote:
> > > Are you aware of such an ORM which both supports WITH and doesn't
> > > also closely track PostgreSQL development? I'm not.
> > >
> > > Even assuming that such a thing exists, it's not at all obvious to
> > > me that we should be stalling and/or putting in what will turn out
> > > to be misfeatures to accommodate it.
> > I know SQLAlchemy does support CTEs, and lags quite considerably in
> > its support of the latest syntactic elements.
> > For instance, it took them 8 months to support the "skip locked"
> > option.
> That is pretty strictly their problem.
> > Not sure whether that qualifies as "closely tracking" postgres for
> > you. Clearly they do track it, but that doesn't mean they're fast or
> > as fast as one would like/need.
> We can NOT make their tardiness a driver of our development.
> > Sure, that might not be enough to warrant the GUC. I would think so,
> > those are my 2 cents. YMMV.
> When we add a "temporary" GUC, we're taking on a gigantic burden.
> Either we support it forever somehow, or we put it on a deprecation
> schedule immediately and expect to be answering questions about it for
> years after it's been removed.
> -1 for the GUC.
Is possible to find consensus without GUC? I understand well, why GUC is
wrong, but I don't see any possible solution how to change current behave
and don't break lot of applications.
> David Fetter <david(at)fetter(dot)org> http://fetter.org/
> Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
> Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
> Remember to vote!
> Consider donating to Postgres: http://www.postgresql.org/about/donate
> Sent via pgsql-hackers mailing list (email@example.com)
> To make changes to your subscription: