hstore ==> and deprecate =>
in [PgSql]
|
From: Robert Haas on 9 Jun 2010 09:33 On Wed, Jun 9, 2010 at 9:06 AM, Dimitri Fontaine <dfontaine(a)hi-media.com> wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >>> What about a WARNING at CREATE OPERATOR time? >> >> That's what the patch I sent already does. > > Great�:) > I read comments in the email instead of the commit� > >> I'm not following this part. > > I'm wondering if deprecating => as an SQL operator, we should too > deprecate its usage in input text for hstore. I don't think so. I don't think so, either. The most someone might want to do is make ==> work wherever => does now, but I wouldn't want to start monkeying with that without some input from Andrew Gierth; and I don't think it's a stop-ship issue for 9.0. Unless there is more than one vote for some alternative other than what I've done here (which so far there isn't), I'm going to add some docs to this patch and commit it later today. Because the SQL committee has standardized an incompatible syntax, there are no perfect alternatives here. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 9 Jun 2010 12:02 Robert Haas <robertmhaas(a)gmail.com> writes: > + if (!strcmp(oprName, "=>")) BTW, project standard is to spell that like > + if (strcmp(oprName, "=>") == 0) The other way looks confusingly like a "not equal" test. > + (errmsg("The use of => as an operator name is deprecated and may be disallowed in a future release."))); Also, this doesn't follow message style guidelines. Possibly better: errmsg("=> is deprecated as an operator name"), errdetail("This name may be disallowed altogether in future versions of PostgreSQL.") regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Andrew Gierth on 9 Jun 2010 12:02 >>>>> "Robert" == Robert Haas <robertmhaas(a)gmail.com> writes: Robert> I don't think so, either. The most someone might want to do Robert> is make ==> work wherever => does now, but I wouldn't want to Robert> start monkeying with that without some input from Andrew Robert> Gierth; and I don't think it's a stop-ship issue for 9.0. I'd really like to find a better operator name than ==>. But I'm not convinced one exists. While I don't like the inconsistency between ==> or whatever and the use of => in type input and output, I regard the text representation as being much harder to change safely, since client code will be parsing it. In this case the inconsistency seems like a much smaller problem than changing the text representation. -- Andrew (irc:RhodiumToad) -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 9 Jun 2010 12:30 Andrew Gierth <andrew(a)tao11.riddles.org.uk> writes: > I'd really like to find a better operator name than ==>. But I'm not > convinced one exists. I agree. > While I don't like the inconsistency between ==> or whatever and the use > of => in type input and output, I regard the text representation as being > much harder to change safely, since client code will be parsing it. In this > case the inconsistency seems like a much smaller problem than changing the > text representation. Perhaps it would be sane to make hstore_in accept either => or ==>, but not change hstore_out (for now)? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 9 Jun 2010 13:04
"David E. Wheeler" <david(a)kineticode.com> writes: > I actually like :> pretty well. It looks more like =>, and has nice correspondence to := for named function params. Colon was removed from the set of allowed operator-name characters years ago. There are conflicts with various usages (ecpg & psql variables). This is actually a place where the current := behavior could cause some issues, though I'm not aware of any at the moment. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |