On Mon, Feb 4, 2013 at 1:06 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > On 2 January 2013 22:51, Robert Haas <robertmh...@gmail.com> wrote: >> On Fri, Dec 28, 2012 at 11:22 AM, Pavel Stehule <pavel.steh...@gmail.com> >> wrote: >>> I am not sure, but maybe is time to introduce ANSI SQL syntax for >>> functions' named parameters >>> >>> It is defined in ANSI SQL 2011 >>> >>> CALL P (B => 1, A => 2) >>> >>> instead PostgreSQL syntax CALL ( B := 1, A := 2) >> >> Keep in mind that, as recently as PostgreSQL 9.1, we shipped hstore >> with a =>(text, text) operator. That operator was deprecated in 9.0, >> but it wasn't actually removed until PostgreSQL 9.2. Whenever we do >> this, it's going to break things for anyone who hasn't yet upgraded >> from hstore v1.0 to hstore v1.1. So I would prefer to wait one more >> release. That way, anyone who does an upgrade, say, every other major >> release cycle should have a reasonably clean upgrade path. > > I don't see why waiting 1 year makes this situation any better. We > just make upgrading to hstore 1.1 a prerequisite and we're done. > > I doubt there are many people using hstore who haven't upgraded, and > fewer still that will upgrade yet can't follow simple instructions on > prerequisites. While hstore is reasonably popular, users are still in > the minority. > > You can always override the operators using a different search_path if > you still see problems there. > > We need to find ways forwards rather than block progress because of > obscure issues.
This seems pretty close to an accusation of bad faith, which I don't believe to be present. Right now there is one and only one release in the field that contains hstore 1.1. If we go ahead and prohibit => as an operator name now, we're going to require everyone who is on 9.1 and uses hstore and wants to get to 9.3 to either (a) first upgrade to 9.2, then update hstore, then upgrade to 9.3; or (b) dig the hstore-1.1 update out of a future release, apply it to an earlier release on which it did not ship, and then upgrade. If they're actually *using* the => operator (rather than just having it in the DB), they'll also need to rewrite their application before doing any of that. Perhaps the users that you support won't mind that, but the users I support will. In fact, they're likely going to mind it even if we have two releases where either version of hstore will work, but at least it will ameliorate the problem somewhat. I find your attitude toward backward compatibility to be astonishingly inconsistent. We haven't made any progress on overhauling recovery.conf in two years because you've steadfastly stonewalled any forward progress on backwards-compatibility grounds, even though a change there can't possible break any working PostgreSQL *application*, only the admin tools. But now, on this change and on a few others, which actually will break applications, you want to push it forward faster. That seems completely backwards to me. In my experience, it is far easier to get people to adjust their admin scripts (which are usually controlled by the same team responsible for the database upgrade anyway) than to get them to fix their applications (which are usually written by a different team over which the DBAs have no real control). We've had customers postpone upgrades for *years* because of issues like this. Labeling it as obscure suggests that it is unimportant or should be dismissed, a conclusion with which I respectfully disagree. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
