On tis, 2011-03-08 at 20:52 -0500, Tom Lane wrote:
> I think we should drop 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 might also ease
Greg Stark writes:
> Can you give an example of what a column definition would look like if
> you put the COLLATE clause in the 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 COLLATE in all the places
On Wed, Mar 9, 2011 at 1:52 AM, 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 . However, it seems to me that that is nonsense up with
> which we should not put.
The SQL comm
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 . However, it seems to me that that is nonsense up with
> which we should not put. is
Another interesting item ... I see that you added a collation field to
TypeName, apparently on the grounds that the SQL spec includes collation
in . However, it seems to me that that is nonsense up with
which we should not put. is basically only used in CAST and
column definitions (plus some fea
Peter Eisentraut 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 must intr
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 oper
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.
Con
Greg Stark writes:
> On Tue, Mar 8, 2011 at 3:21 PM, Tom Lane 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 i
On Tue, Mar 8, 2011 at 3:21 PM, Tom Lane 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 to duplicate tha
Martijn van Oosterhout 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 collation should b
Susanne Ebrecht 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
> encoding depending.
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(), l
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
Martijn van Oosterhout 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.
> A pathkey r
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 was
Peter Eisentraut 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 equal() mus
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 usi
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 indcollation to identify
the sort order of an index. I
19 matches
Mail list logo
