On Tue, Feb 15, 2011 at 7:13 AM, Robert Haas wrote:
> On Tue, Feb 15, 2011 at 4:31 AM, Itagaki Takahiro
> wrote:
>> array_flatten() no longer exists. I added array_trim() as an alias
>> to trim_array() because it would be a FAQ.
>
> I don't like the alias thing - let's add one name or the other,
On Tue, Feb 15, 2011 at 4:31 AM, Itagaki Takahiro
wrote:
> array_flatten() no longer exists. I added array_trim() as an alias
> to trim_array() because it would be a FAQ.
I don't like the alias thing - let's add one name or the other, not both.
Similarly, let's NOT add array_union_all as an alia
Itagaki,
* Itagaki Takahiro (itagaki.takah...@gmail.com) wrote:
> On Sat, Feb 12, 2011 at 05:01, Stephen Frost wrote:
> > What does the spec say about this, if anything? Is that required by
> > spec, or is the spec not relevant to this because MULTISETs are only one
> > dimensional..?
>
> Yes.
On Sat, Feb 12, 2011 at 05:01, Stephen Frost wrote:
> Input arrays are always flattened into one-dimensional arrays.
> That just strikes me as completely broken when it comes to PG Arrays.
Contains operators (<@, &&, @>) ignore multi-dimensions.
Array slice operator ([lo:hi]) always reset the ind
* Itagaki Takahiro (itagaki.takah...@gmail.com) wrote:
> I will remove parser changes from the patch; it will add only a few array
> functions. Then, please let me know functions you don't want to include
> in the core, if any. I'll remove them at the same time.
Seems like this should be 'waiting
On Fri, Feb 11, 2011 at 11:17 AM, Itagaki Takahiro
wrote:
> Did you measure the actual cost in the real world? If we are using
> such a sensitive parser, it should be a problem even without the patch.
It *is* a problem without the patch!
>> Adding unnecessary keywords is something to be avoided.
On Sat, Feb 12, 2011 at 00:50, Tom Lane wrote:
> Robert Haas writes:
>> Right, but making the parser slower has a cost, too.
>> ScanKeywordLookup() is already a hotspot in some workloads, and
>> there's overhead buried in the bison parser, too.
>
> Yeah. Keep in mind that a bison parser fundamen
Robert Haas writes:
> Right, but making the parser slower has a cost, too.
> ScanKeywordLookup() is already a hotspot in some workloads, and
> there's overhead buried in the bison parser, too.
Yeah. Keep in mind that a bison parser fundamentally runs off a
two-dimensional array: one axis is pars
On Fri, Feb 4, 2011 at 9:11 PM, Itagaki Takahiro
wrote:
> On Sat, Feb 5, 2011 at 04:24, Dimitri Fontaine wrote:
>>> In math class, maybe. But in programming, no. Multiset is a
>>> datatype. Array is a different datatype. There is no reason why we
>>> need to clutter our parser with extra keyw
On Sat, Feb 5, 2011 at 04:24, Dimitri Fontaine wrote:
>> In math class, maybe. But in programming, no. Multiset is a
>> datatype. Array is a different datatype. There is no reason why we
>> need to clutter our parser with extra keywords to support a
>> non-standard feature extension.
>
> My un
Robert Haas writes:
> On Fri, Feb 4, 2011 at 1:15 PM, Itagaki Takahiro
> wrote:
>> Multisets. But I chose the same function name and syntax because
>> arrays *are* multisets by definition.
>
> In math class, maybe. But in programming, no. Multiset is a
> datatype. Array is a different datatype
On Fri, Feb 4, 2011 at 1:15 PM, Itagaki Takahiro
wrote:
> On Sat, Feb 5, 2011 at 03:04, Robert Haas wrote:
I am still not in favor of adding this syntax.
>>>
>>> I also don't like the syntax, but unfortunately, almost all of
>>> them are in the SQL standard :-(.
>>
>> The standard specifies
On Sat, Feb 5, 2011 at 03:04, Robert Haas wrote:
>>> I am still not in favor of adding this syntax.
>>
>> I also don't like the syntax, but unfortunately, almost all of
>> them are in the SQL standard :-(.
>
> The standard specifies this syntax for arrays, or for multisets?
Multisets. But I chose
On Fri, Feb 4, 2011 at 1:02 PM, Itagaki Takahiro
wrote:
> On Sat, Feb 5, 2011 at 02:29, Robert Haas wrote:
>> I am still not in favor of adding this syntax.
>
> I also don't like the syntax, but unfortunately, almost all of
> them are in the SQL standard :-(.
The standard specifies this syntax f
On Sat, Feb 5, 2011 at 02:29, Robert Haas wrote:
> I am still not in favor of adding this syntax.
I also don't like the syntax, but unfortunately, almost all of
them are in the SQL standard :-(. In addition, Oracle already
uses the same feature with the special syntax, though true multiset
data
On Mon, Jan 31, 2011 at 1:49 AM, Itagaki Takahiro
wrote:
> I removed collect() aggregate function because the result type is MULTISET
> in the spec. I keep all of other functions and operators because they won't
> break anything in the standard. When we will have true MULTISET data type,
> we can
On Mon, Jan 31, 2011 at 04:12, Robert Haas wrote:
>> Well, do you want to revise this and submit a stripped-down version?
>> I'm not averse to adding things that are required by the standard and
>> won't cause backward compatibility problems later.
Sure. I'll remove collect() function. I can also
On Sun, Jan 30, 2011 at 2:11 PM, Robert Haas wrote:
> On Sun, Jan 30, 2011 at 1:46 PM, Itagaki Takahiro
> wrote:
>> On Mon, Jan 31, 2011 at 02:34, Robert Haas wrote:
> I'm in favor of rejecting this patch in its entirety. The
> functionality looks useful, but once you remove the syntax
On Sun, Jan 30, 2011 at 1:46 PM, Itagaki Takahiro
wrote:
> On Mon, Jan 31, 2011 at 02:34, Robert Haas wrote:
I'm in favor of rejecting this patch in its entirety. The
functionality looks useful, but once you remove the syntax support, it
could just as easily be distributed as a co
On Mon, Jan 31, 2011 at 02:34, Robert Haas wrote:
>>> I'm in favor of rejecting this patch in its entirety. The
>>> functionality looks useful, but once you remove the syntax support, it
>>> could just as easily be distributed as a contrib module rather than in
>>> core.
>>
>> +1 ... if we're goi
On Sun, Jan 30, 2011 at 12:16 PM, Tom Lane wrote:
> Robert Haas writes:
>> So, the plan is to add this now with non-standard semantics and then
>> change the semantics later if and when we implement what the standard
>> requires? That's not something we usually do, and I don't see why
>> it's a
2011/1/30 Robert Haas :
> On Mon, Jan 24, 2011 at 7:27 AM, Itagaki Takahiro
> wrote:
>> On Mon, Jan 24, 2011 at 20:49, Robert Haas wrote:
>>> I notice that this is adding keywords and syntax support for what is
>>> basically a PostgreSQL extension (since we certainly can't possibly be
>>> followi
Robert Haas writes:
> So, the plan is to add this now with non-standard semantics and then
> change the semantics later if and when we implement what the standard
> requires? That's not something we usually do, and I don't see why
> it's a better idea in this case than it is in general. It's OK
On Mon, Jan 24, 2011 at 7:27 AM, Itagaki Takahiro
wrote:
> On Mon, Jan 24, 2011 at 20:49, Robert Haas wrote:
>> I notice that this is adding keywords and syntax support for what is
>> basically a PostgreSQL extension (since we certainly can't possibly be
>> following the SQL standards given that
On Mon, Jan 24, 2011 at 20:49, Robert Haas wrote:
> I notice that this is adding keywords and syntax support for what is
> basically a PostgreSQL extension (since we certainly can't possibly be
> following the SQL standards given that we're not implementing a new
> datatype. Is that really a good
On Mon, Jan 24, 2011 at 2:45 AM, Itagaki Takahiro
wrote:
> [ latest patch ]
I notice that this is adding keywords and syntax support for what is
basically a PostgreSQL extension (since we certainly can't possibly be
following the SQL standards given that we're not implementing a new
datatype. Is
On Wed, Jan 12, 2011 at 23:29, Alvaro Herrera
wrote:
> Two small nitpicks:
> + check_concatinatable(Oid element_type1, Oid element_type2)
> + ereport(ERROR,
> + (errcode(ERRCODE_DATATYPE_MISMATCH),
> + errmsg("cannot concatenate incompatible arrays"),
> +
Excerpts from Itagaki Takahiro's message of mié ene 12 01:52:12 -0300 2011:
> Separate patches for src and doc attached. It includes a few bug fixes
> and cleanup. I changed the error code in trim_array() to
> ERRCODE_ARRAY_ELEMENT_ERROR according to the spec.
Two small nitpicks:
+ static void
+
2011/1/12 Pavel Stehule :
> 2011/1/12 Itagaki Takahiro :
>> On Wed, Jan 12, 2011 at 20:18, Pavel Stehule wrote:
>>> there is one issue - probably useless checking a type equality in
>>> function check_comparable and check_concatinatable, because when your
>>> function is registrated with arguments
2011/1/12 Itagaki Takahiro :
> On Wed, Jan 12, 2011 at 20:18, Pavel Stehule wrote:
>> there is one issue - probably useless checking a type equality in
>> function check_comparable and check_concatinatable, because when your
>> function is registrated with arguments (anyarray, anyarray), then is
>
On Wed, Jan 12, 2011 at 20:18, Pavel Stehule wrote:
> there is one issue - probably useless checking a type equality in
> function check_comparable and check_concatinatable, because when your
> function is registrated with arguments (anyarray, anyarray), then is
> guaranteed so type of array1 is s
Hello
there is one issue - probably useless checking a type equality in
function check_comparable and check_concatinatable, because when your
function is registrated with arguments (anyarray, anyarray), then is
guaranteed so type of array1 is same as type of array2, and then you
don't need to chec
On Wed, Jan 12, 2011 at 15:21, Peter Eisentraut wrote:
> You may want to read this thread about the cardinality function are you
> trying to add:
>
> http://archives.postgresql.org/pgsql-hackers/2009-02/msg01388.php
Since our archive is split per month, this might be more readable:
http://postgre
On ons, 2011-01-12 at 13:52 +0900, Itagaki Takahiro wrote:
> I added a short description about MULTISET and example of operators
> in "Arrays > 8.14.7. Multiset Support" section in the docs.
> Is it enough? or what kind of information do you want?
>
> Separate patches for src and doc attached. It
Patching:
patching file doc/src/sgml/func.sgml
Hunk #6 succeeded at 10567 (offset 1 line).
Hunk #7 succeeded at 10621 (offset 1 line).
Hunk #8 succeeded at 10721 (offset 1 line).
Hunk #9 succeeded at 10775 (offset 1 line).
patching file src/backend/nodes/makefuncs.c
patching file src/backend/parse
35 matches
Mail list logo
