Robert Haas writes:
> On Thu, Feb 7, 2013 at 6:42 AM, Simon Riggs wrote:
>> IMO the way to resolve that conflict is with a behaviour parameter to
>> allow people to choose, rather than be forced to wait a year because
>> some people still run an old version of an add-on package. A good way
>> to
Tom Lane writes:
> If you're suggesting that we should back-patch hstore 1.1 into 9.1,
> there might not be a technical reason why we couldn't do it, but there
> are certainly project-policy reasons. Removing operators, or indeed
> changing any SQL interface at all, is exactly the kind of change
Dimitri Fontaine writes:
> Robert Haas writes:
>> I don't know what to add to that.
> There's no technical reason that I'm aware of for hstore 1.1 not to
> support all our maintained releases at the same time. That's exactly how
> we do it with non-core extensions, by the way.
If you're suggest
Robert Haas writes:
> $ 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
On Thu, Feb 7, 2013 at 6:42 AM, Simon Riggs wrote:
> IMO the way to resolve that conflict is with a behaviour parameter to
> allow people to choose, rather than be forced to wait a year because
> some people still run an old version of an add-on package. A good way
> to do that would be to have a
On 6 February 2013 20:31, Robert Haas wrote:
> On Wed, Feb 6, 2013 at 1:06 PM, Simon Riggs wrote:
>> On 6 February 2013 17:43, Robert Haas wrote:
>>> On Mon, Feb 4, 2013 at 3:32 PM, Simon Riggs wrote:
On 4 February 2013 19:53, Robert Haas wrote:
> This seems pretty close to an accusat
On Wed, Feb 6, 2013 at 1:06 PM, Simon Riggs wrote:
> On 6 February 2013 17:43, Robert Haas wrote:
>> On Mon, Feb 4, 2013 at 3:32 PM, Simon Riggs wrote:
>>> On 4 February 2013 19:53, Robert Haas wrote:
This seems pretty close to an accusation of bad faith, which I don't
believe to be p
On 6 February 2013 17:43, Robert Haas wrote:
> On Mon, Feb 4, 2013 at 3:32 PM, Simon Riggs wrote:
>> On 4 February 2013 19:53, Robert Haas wrote:
>>> This seems pretty close to an accusation of bad faith, which I don't
>>> believe to be present.
>>
>> Robert, this is not an accusation of bad fai
On Mon, Feb 4, 2013 at 3:32 PM, Simon Riggs wrote:
> On 4 February 2013 19:53, Robert Haas wrote:
>> This seems pretty close to an accusation of bad faith, which I don't
>> believe to be present.
>
> Robert, this is not an accusation of bad faith, just an observation
> that we can move forwards m
2013/2/4 Robert Haas :
> On Mon, Feb 4, 2013 at 1:06 PM, Simon Riggs wrote:
>> On 2 January 2013 22:51, Robert Haas wrote:
>>> On Fri, Dec 28, 2012 at 11:22 AM, Pavel Stehule
>>> wrote:
I am not sure, but maybe is time to introduce ANSI SQL syntax for
functions' named parameters
On 4 February 2013 19:53, Robert Haas wrote:
> This seems pretty close to an accusation of bad faith, which I don't
> believe to be present.
Robert, this is not an accusation of bad faith, just an observation
that we can move forwards more quickly.
I understand completely why you wish to make s
On Mon, Feb 4, 2013 at 1:06 PM, Simon Riggs wrote:
> On 2 January 2013 22:51, Robert Haas wrote:
>> On Fri, Dec 28, 2012 at 11:22 AM, Pavel Stehule
>> wrote:
>>> I am not sure, but maybe is time to introduce ANSI SQL syntax for
>>> functions' named parameters
>>>
>>> It is defined in ANSI SQL 2
On 2 January 2013 22:51, Robert Haas wrote:
> On Fri, Dec 28, 2012 at 11:22 AM, Pavel Stehule
> 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
2013/2/4 Gavin Flower :
> On 04/02/13 21:55, Pavel Stehule wrote:
>
> 2013/1/2 Robert Haas :
>
> On Fri, Dec 28, 2012 at 11:22 AM, Pavel Stehule
> 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
On 04/02/13 21:55, Pavel Stehule wrote:
2013/1/2 Robert Haas :
On Fri, Dec 28, 2012 at 11:22 AM, Pavel Stehule 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 syn
2013/1/2 Robert Haas :
> On Fri, Dec 28, 2012 at 11:22 AM, Pavel Stehule
> 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,
Hello
2013/1/2 Robert Haas :
> On Fri, Dec 28, 2012 at 11:22 AM, Pavel Stehule
> 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
On Fri, Dec 28, 2012 at 11:22 AM, Pavel Stehule 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 recen
2012/12/28 Gavin Flower :
> On 29/12/12 10:19, Peter Eisentraut wrote:
>
> On 12/28/12 11:22 AM, Pavel Stehule 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 Postg
On 29/12/12 10:19, Peter Eisentraut wrote:
On 12/28/12 11:22 AM, Pavel Stehule 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)
I agre
On 12/28/12 11:22 AM, Pavel Stehule 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)
I agree it's probably time.
> * shou
Hello
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)
Patch is very simple, but there are lot of questions about support
previous syntax.
* sh
22 matches
Mail list logo
