Robert Haas writes:
> The point was that if you want to bikeshed, please do it on the OTHER
> thread, not this one. :-)
Ouch, asking for bikeshed and understanding what you read around… I
call that a trap ;)
--
dim
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Robert Haas writes:
> On Mon, Jun 21, 2010 at 1:24 PM, Tom Lane wrote:
>> in particular, s/may/will/ and avoid passive voice in the second sentence.
> Avoiding the passive voice is a good idea, and I like your suggested
> phrasing. I'm reluctant to say what we "will" do in a future release
> be
On Mon, Jun 21, 2010 at 1:46 PM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>
>> By consensus, we have removed the new-to-9.0 operator text[] => text[]
>> and renamed the hstore => text[] operator. (The current name is "%",
>> but there is some discussion of "%>", some yet other name, or gett
Robert Haas writes:
> By consensus, we have removed the new-to-9.0 operator text[] => text[]
> and renamed the hstore => text[] operator. (The current name is "%",
> but there is some discussion of "%>", some yet other name, or getting
> rid of it altogether; please comment on that thread if you
On Mon, Jun 21, 2010 at 1:24 PM, Tom Lane wrote:
> Robert Haas writes:
>> Barring vigorous objections, I will apply these tomorrow so that we
>> can consider deprecating => as an operator name in 9.1, for better
>> compliance with the SQL standard.
>
> Two documentation comments:
>
> 1. Perhaps,
Robert Haas writes:
> Barring vigorous objections, I will apply these tomorrow so that we
> can consider deprecating => as an operator name in 9.1, for better
> compliance with the SQL standard.
Two documentation comments:
1. Perhaps, rather than
> + The => operator is deprecated and may be r
On Mon, Jun 21, 2010 at 12:37 PM, David E. Wheeler wrote:
>> Barring vigorous objections, I will apply these tomorrow so that we
>> can consider deprecating => as an operator name in 9.1, for better
>> compliance with the SQL standard.
>
> So will the CREATE OPERATOR code be updated to issue the w
On Mon, Jun 21, 2010 at 12:40 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of lun jun 21 12:20:59 -0400 2010:
>
>> Barring vigorous objections, I will apply these tomorrow so that we
>> can consider deprecating => as an operator name in 9.1, for better
>> compliance with the SQL
Excerpts from Robert Haas's message of lun jun 21 12:20:59 -0400 2010:
> Barring vigorous objections, I will apply these tomorrow so that we
> can consider deprecating => as an operator name in 9.1, for better
> compliance with the SQL standard.
Maybe this is just a matter of semantics, but I tho
On Jun 21, 2010, at 9:20 AM, Robert Haas wrote:
> Per that email, and subsequent concurrence, here is a series of
> patches which does the following:
>
> 1. In CVS HEAD, document the hstore(text, text) function and adjust
> CREATE OPERATOR to throw a warning when => is used as an operator
> name,
By consensus, we have removed the new-to-9.0 operator text[] => text[]
and renamed the hstore => text[] operator. (The current name is "%",
but there is some discussion of "%>", some yet other name, or getting
rid of it altogether; please comment on that thread if you wish to
weigh in.) This mean
11 matches
Mail list logo
