[HACKERS] collation, arrays, and ranges
My interpretation of collation for range types is different than that for arrays, so I'm presenting it here in case someone has an objection. An array type has the same typcollation as its element type. This makes sense, because comparison between arrays are affected by the COLLATE clause. Comparison between ranges should not be affected by the COLLATE clause (as we discussed). So, I chose to represent that as a separate rngcollation and leave the typcollation 0. In other words, collation is a concept internal to that range type and fixed at type definition time. Range types are affected by their internal collation, but don't take part in the logic that passes collation through the type system. Comments? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] collation, arrays, and ranges
My interpretation of collation for range types is different than that for arrays, so I'm presenting it here in case someone has an objection. An array type has the same typcollation as its element type. This makes sense, because comparison between arrays are affected by the COLLATE clause. Comparison between ranges should not be affected by the COLLATE clause (as we discussed). So, I chose to represent that as a separate rngcollation and leave the typcollation 0. In other words, collation is a concept internal to that range type and fixed at type definition time. Range types are affected by their internal collation, but don't take part in the logic that passes collation through the type system. Comments? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] collation, arrays, and ranges
Jeff Davis pg...@j-davis.com writes: My interpretation of collation for range types is different than that for arrays, so I'm presenting it here in case someone has an objection. An array type has the same typcollation as its element type. This makes sense, because comparison between arrays are affected by the COLLATE clause. Comparison between ranges should not be affected by the COLLATE clause (as we discussed). Check. So, I chose to represent that as a separate rngcollation and leave the typcollation 0. In other words, collation is a concept internal to that range type and fixed at type definition time. Range types are affected by their internal collation, but don't take part in the logic that passes collation through the type system. Should I read that as saying you want to add yet another column to pg_type? I'd prefer not to do that. Seems to me we could still store the value in typcollation, but just interpret the column a bit differently depending on typtype. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] collation, arrays, and ranges
On Sat, 2011-09-10 at 13:21 -0400, Tom Lane wrote: So, I chose to represent that as a separate rngcollation and leave the typcollation 0. In other words, collation is a concept internal to that range type and fixed at type definition time. Range types are affected by their internal collation, but don't take part in the logic that passes collation through the type system. Should I read that as saying you want to add yet another column to pg_type? I'd prefer not to do that. Seems to me we could still store the value in typcollation, but just interpret the column a bit differently depending on typtype. I added the column to pg_range (rngcollation), which seemed a little less invasive than either of the other options (either adding a new column to pg_type or overloading the existing one). I was worried about having the same column in pg_type mean two different things -- every caller of get_typcollation would need to be careful. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
