On Wed, Mar 9, 2011 at 1:52 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Another interesting item ... I see that you added a collation field to
TypeName, apparently on the grounds that the SQL spec includes collation
in data type. However, it seems to me that that is nonsense up with
which we
Greg Stark gsst...@mit.edu writes:
Can you give an example of what a column definition would look like if
you put the COLLATE clause in the data type in a way that wouldn't
be parsed according to your plan?
Column definitions look and act the same. The point of the change is to
not accept
On tis, 2011-03-08 at 20:52 -0500, Tom Lane wrote:
I think we should drop collate clause from TypeName and just have it
in columnDef and the expression syntax.
Yes, that sounds better in retrospect. It's easier to see that now that
we see all the cases where it's used and not used.
This
On Tue, Mar 08, 2011 at 08:52:41PM -0500, Tom Lane wrote:
Another interesting item ... I see that you added a collation field to
TypeName, apparently on the grounds that the SQL spec includes collation
in data type. However, it seems to me that that is nonsense up with
which we should not
On Mon, Mar 07, 2011 at 07:15:28PM -0500, Tom Lane wrote:
Only if the expression-to-be-sorted does not already fully specify the
collation, which so far as I can tell (either from the code or your
description above) it does. I think that the explicit representation
of collation as part of the
On 07.03.2011 17:43, Tom Lane wrote:
because two expressions that are equal() must necessarily have the same
collation
property.
Peter, Tom,
I am not able to see this.
If 'abc' == 'abc' is not collation depending at all. It is only
encoding depending.
Collation is only needed for upper(),
Susanne Ebrecht susa...@2ndquadrant.com writes:
On 07.03.2011 17:43, Tom Lane wrote:
because two expressions that are equal() must necessarily have the same
collation
property.
Peter, Tom,
I am not able to see this.
If 'abc' == 'abc' is not collation depending at all. It is only
Martijn van Oosterhout klep...@svana.org writes:
This phase of processing happens in the parse analysis, the end result
being that every expression should have a collation set, and every
operator where it matters has consistant collation information for its
arguments. So at this point the
On Tue, Mar 8, 2011 at 3:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Not so right. A path key contains an expression tree, plus whatever
*additional* information is needed to fully specify the sort ordering.
If the collation is already fully determined by the expression tree,
there is no need
Greg Stark gsst...@mit.edu writes:
On Tue, Mar 8, 2011 at 3:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Not so right. A path key contains an expression tree, plus whatever
*additional* information is needed to fully specify the sort ordering.
If the collation is already fully determined by the
On mån, 2011-03-07 at 12:52 -0500, Tom Lane wrote:
It looks like indcollation is acting as a
substitute for including a CollateClause in the index key expression,
which doesn't seem like a particularly good tradeoff considering all
the overhead you must introduce into the default case.
On mån, 2011-03-07 at 19:15 -0500, Tom Lane wrote:
Or, to put it another way: the properties that define a sort order are
the sort comparison operator, the collation, the ASC/DESC bit, and the
NULLS FIRST/LAST bit. Given the way that the SQL committee has
constructed the language, the
Peter Eisentraut pete...@gmx.net writes:
On mån, 2011-03-07 at 12:52 -0500, Tom Lane wrote:
It looks like indcollation is acting as a
substitute for including a CollateClause in the index key expression,
which doesn't seem like a particularly good tradeoff considering all
the overhead you
Another interesting item ... I see that you added a collation field to
TypeName, apparently on the grounds that the SQL spec includes collation
in data type. However, it seems to me that that is nonsense up with
which we should not put. data type is basically only used in CAST and
column
On mån, 2011-03-07 at 11:43 -0500, Tom Lane wrote:
Is there any documentation of $SUBJECT? Because the more I look at
this patch the more I think it's misdesigned; either that or I
fundamentally misunderstand what it's trying to do. I complained
yesterday about why the planner wasn't using
Peter Eisentraut pete...@gmx.net writes:
On mån, 2011-03-07 at 11:43 -0500, Tom Lane wrote:
... I now think that the reason it doesn't
obviously fail to fail is that indcollation is dead code, and so is
approximately 99% of what you added to the planner, because two
expressions that are
On Mon, Mar 07, 2011 at 11:43:20AM -0500, Tom Lane wrote:
Is there any documentation of $SUBJECT? Because the more I look at
this patch the more I think it's misdesigned; either that or I
fundamentally misunderstand what it's trying to do. I complained
yesterday about why the planner wasn't
Martijn van Oosterhout klep...@svana.org writes:
On Mon, Mar 07, 2011 at 11:43:20AM -0500, Tom Lane wrote:
Is there any documentation of $SUBJECT?
The collation is a property of the operators/functions and not of the
values. An individual value does not have a collation, a column does.
OK.
18 matches
Mail list logo
