12 Commits (210f95f1cd59c6fdfe0f84b922c19d8498ac377d)

Author	SHA1	Message	Date
Tom Lane	f89e4dfa75	Remove collate.linux.utf8.sql's assumptions about ".utf8" in locale names. ... Tweak the test so that it does not depend on the platform using ".utf8" as the extension signifying that a locale uses UTF8 encoding. For the most part this just requires using the abbreviated collation names "en_US" etc, though I had to work a bit harder on the collation creation tests. This opens the door to using the test on platforms that spell locales differently, for example ".utf-8" or ".UTF-8". Also, the test is now somewhat useful with server encodings other than UTF8; though depending on which encoding is selected, different subsets of it will fail for lack of character set support.	15 years ago
Tom Lane	a19002d4e5	Adjust collation determination rules as per discussion. ... Remove crude hack that tried to propagate collation through a function-returning-record, ie, from the function's arguments to individual fields selected from its result record. That is just plain inconsistent, because the function result is composite and cannot have a collation; and there's no hope of making this kind of action-at-a-distance work consistently. Adjust regression test cases that expected this to happen. Meanwhile, the behavior of casting to a domain with a declared collation stays the same as it was, since that seemed to be the consensus.	15 years ago
Tom Lane	a4425e3200	Fix collation handling in plpgsql functions. ... Make plpgsql treat the input collation as a polymorphism variable, so that we cache separate plans for each input collation that's used in a particular session, as per recent discussion. Propagate the input collation to all collatable input parameters. I chose to also propagate the input collation to all declared variables of collatable types, which is a bit more debatable but seems to be necessary for non-astonishing behavior. (Copying a parameter into a separate local variable shouldn't result in a change of behavior, for example.) There is enough infrastructure here to support declaring a collation for each local variable to override that default, but I thought we should wait to see what the field demand is before adding such a feature. In passing, remove exec_get_rec_fieldtype(), which wasn't used anywhere. Documentation patch to follow.	15 years ago
Tom Lane	27dc7e240b	Fix handling of collation in SQL-language functions. ... Ensure that parameter symbols receive collation from the function's resolved input collation, and fix inlining to behave properly. BTW, this commit lays about 90% of the infrastructure needed to support use of argument names in SQL functions. Parsing of parameters is now done via the parser-hook infrastructure ... we'd just need to supply a column-ref hook ...	15 years ago
Tom Lane	3bba9ce945	Clean up handling of COLLATE clauses in index column definitions. ... Ensure that COLLATE at the top level of an index expression is treated the same as a grammatically separate COLLATE. Fix bogus reverse-parsing logic in pg_get_indexdef.	15 years ago
Tom Lane	37d6d07dda	Throw error for indeterminate collation of an ORDER/GROUP/DISTINCT target. ... This restores a parse error that was thrown (though only in the ORDER BY case) by the original collation patch. I had removed it in my recent revisions because it was thrown at a place where collations now haven't been computed yet; but I thought of another way to handle it. Throwing the error at parse time, rather than leaving it to be done at runtime, is good because a syntax error pointer is helpful for localizing the problem. We can reasonably assume that the comparison function for a collatable datatype will complain if it doesn't have a collation to use. Now the planner might choose to implement GROUP or DISTINCT via hashing, in which case no runtime error would actually occur, but it seems better to throw error consistently rather than let the error depend on what the planner chooses to do. Another possible objection is that the user might specify a nondefault sort operator that doesn't care about collation ... but that's surely an uncommon usage, and it wouldn't hurt him to throw in a COLLATE clause anyway. This change also makes the ORDER BY/GROUP BY/DISTINCT case more consistent with the UNION/INTERSECT/EXCEPT case, which was already coded to throw this error even though the same objections could be raised there.	15 years ago
Tom Lane	b310b6e31c	Revise collation derivation method and expression-tree representation. ... All expression nodes now have an explicit output-collation field, unless they are known to only return a noncollatable data type (such as boolean or record). Also, nodes that can invoke collation-aware functions store a separate field that is the collation value to pass to the function. This avoids confusion that arises when a function has collatable inputs and noncollatable output type, or vice versa. Also, replace the parser's on-the-fly collation assignment method with a post-pass over the completed expression tree. This allows us to use a more complex (and hopefully more nearly spec-compliant) assignment rule without paying for it in extra storage in every expression node. Fix assorted bugs in the planner's handling of collations by making collation one of the defining properties of an EquivalenceClass and by converting CollateExprs into discardable RelabelType nodes during expression preprocessing.	15 years ago
Peter Eisentraut	3d9f7ec1ff	Add test case for collation mismatch in recursive query ... This isn't very important by itself, but was left on my list of things without test coverage for the collation feature.	15 years ago
Peter Eisentraut	b9cff97fdf	Don't allow CREATE TABLE AS to create a column with invalid collation ... It is possible that an expression ends up with a collatable type but without a collation. CREATE TABLE AS could then create a table based on that. But such a column cannot be dumped with valid SQL syntax, so we disallow creating such a column. per test report from Noah Misch	15 years ago
Peter Eisentraut	4442e1975d	When creating a collation, check that the locales can be loaded ... This is the same check that would happen later when the collation is used, but it's friendlier to check the collation already when it is created.	15 years ago
Peter Eisentraut	b313bca0af	DDL support for collations ... - collowner field - CREATE COLLATION - ALTER COLLATION - DROP COLLATION - COMMENT ON COLLATION - integration with extensions - pg_dump support for the above - dependency management - psql tab completion - psql \dO command	15 years ago
Peter Eisentraut	414c5a2ea6	Per-column collation support ... This adds collation support for columns and domains, a COLLATE clause to override it per expression, and B-tree index support. Peter Eisentraut reviewed by Pavel Stehule, Itagaki Takahiro, Robert Haas, Noah Misch	15 years ago