On Mon, 2011-04-18 at 10:41 -0400, Tom Lane wrote:
> However, I've come across a new issue that maybe requires discussion:
> what collation should be associated with a multi-row VALUES in FROM?
> For instance, in
>
> SELECT ... FROM
> (VALUES (1, 'foo'), (2, 'bar' COLLATE "C")) v
Robert Haas writes:
> [ assorted comments on original issues ]
I believe that all the collation issues I complained about on 26 March
are now resolved, except for the question of getting some more test
cases, and the question of adding a cares-about-collation flag to
pg_proc. I've added the latt
Peter Eisentraut writes:
> On mån, 2011-03-28 at 20:02 -0400, Tom Lane wrote:
>> One thing I noticed but didn't push to committing is that the test
>> case has a largely-unnecessary assumption about how the local system's
>> locale names spell "utf8". We could eliminate that by having it use
>>
On mån, 2011-03-28 at 20:02 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > On lör, 2011-03-26 at 00:36 -0400, Tom Lane wrote:
> >> * It'd sure be nice if we had some nontrivial test cases that work
> >> in encodings besides UTF8. I'm still bothered that the committed
> >> patch failed to c
Excerpts from Peter Eisentraut's message of sáb abr 09 01:32:28 -0300 2011:
> On fre, 2011-04-08 at 16:14 -0300, Alvaro Herrera wrote:
> > Excerpts from Tom Lane's message of vie abr 08 15:27:15 -0300 2011:
> > > Peter Eisentraut writes:
> > > > On lör, 2011-03-26 at 00:36 -0400, Tom Lane wrote:
>
On fre, 2011-04-08 at 16:14 -0300, Alvaro Herrera wrote:
> Excerpts from Tom Lane's message of vie abr 08 15:27:15 -0300 2011:
> > Peter Eisentraut writes:
> > > On lör, 2011-03-26 at 00:36 -0400, Tom Lane wrote:
> > >> * Remove initdb's warning about useless locales? Seems like pointless
> > >>
Excerpts from Tom Lane's message of vie abr 08 15:27:15 -0300 2011:
> Peter Eisentraut writes:
> > On lör, 2011-03-26 at 00:36 -0400, Tom Lane wrote:
> >> * Remove initdb's warning about useless locales? Seems like pointless
> >> noise, or at least something that can be relegated to debug mode.
>
Peter Eisentraut writes:
> On lör, 2011-03-26 at 00:36 -0400, Tom Lane wrote:
>> * Remove initdb's warning about useless locales? Seems like pointless
>> noise, or at least something that can be relegated to debug mode.
> Quick question on this: Should we at least warn if zero suitable
> local
On lör, 2011-03-26 at 00:36 -0400, Tom Lane wrote:
> * Remove initdb's warning about useless locales? Seems like pointless
> noise, or at least something that can be relegated to debug mode.
Quick question on this: Should we at least warn if zero suitable
locales were found or some other problem
Robert Haas writes:
> Reading through this thread...
> On Sat, Mar 26, 2011 at 12:36 AM, Tom Lane wrote:
>> ** Selecting a field from a record-returning function's output.
>> Currently, we'll use the field's declared collation; except that
>> if the field has default collation, we'll replace that
Reading through this thread...
On Sat, Mar 26, 2011 at 12:36 AM, Tom Lane wrote:
> ** Selecting a field from a record-returning function's output.
> Currently, we'll use the field's declared collation; except that
> if the field has default collation, we'll replace that with the common
> collatio
On Mon, Mar 28, 2011 at 08:02:40PM -0400, Tom Lane wrote:
> One thing I noticed but didn't push to committing is that the test case
> has a largely-unnecessary assumption about how the local system's locale
> names spell "utf8". We could eliminate that by having it use the
> trimmed locale names c
Em 28-03-2011 22:27, Alvaro Herrera escreveu:
Excerpts from Tom Lane's message of lun mar 28 21:02:40 -0300 2011:
I tried. The upper/lower test cases require Turkish characters that
aren't in Latin1. I'm not sure if we can readily produce test cases
that cover both sorting changes and case-fol
Excerpts from Tom Lane's message of lun mar 28 21:02:40 -0300 2011:
> Peter Eisentraut writes:
> > On lör, 2011-03-26 at 00:36 -0400, Tom Lane wrote:
> >> * It'd sure be nice if we had some nontrivial test cases that work in
> >> encodings besides UTF8. I'm still bothered that the committed patch
Peter Eisentraut writes:
> On lör, 2011-03-26 at 00:36 -0400, Tom Lane wrote:
>> * It'd sure be nice if we had some nontrivial test cases that work in
>> encodings besides UTF8. I'm still bothered that the committed patch
>> failed to cover single-byte-encoding cases in upper/lower/initcap.
> W
On lör, 2011-03-26 at 00:36 -0400, Tom Lane wrote:
> * RI triggers should insert COLLATE clauses in generated queries to
> satisfy SQL2008 9.13 SR 4a, which says that RI comparisons use the
> referenced column's collation. Right now you may get either table's
> collation depending on which query t
On Sun, Mar 27, 2011 at 03:14:37PM -0400, Tom Lane wrote:
> > So the result of a cast would be the collation of the specified
> > type/domain with state implicit.
>
> Hm. That makes sense for explicit CAST syntax, but what about a
> function returning a collatable type? In particular, applying t
Martijn van Oosterhout writes:
> On Sat, Mar 26, 2011 at 12:36:43AM -0400, Tom Lane wrote:
>> ** Selecting a field from a record-returning function's output.
>> Currently, we'll use the field's declared collation; except that
>> if the field has default collation, we'll replace that with the commo
On Sat, Mar 26, 2011 at 12:36:43AM -0400, Tom Lane wrote:
> ** Selecting a field from a record-returning function's output.
> Currently, we'll use the field's declared collation; except that
> if the field has default collation, we'll replace that with the common
> collation of the function's input
On Mar 26, 2011, at 12:34 PM, Greg Stark wrote:
> The ones with the collation expressions inside the casts seem very
> strange and the behaviour following the domain don't seem
> unreasonable. The behaviour with the collate clauses outside the cast
> should definitely be follow the explicit collat
On Sat, Mar 26, 2011 at 3:16 PM, Robert Haas wrote:
>> ** What to do with domains whose declaration includes a COLLATE clause?
>> Currently, we'll impute that collation to the result of a cast to the
>> domain type --- even if the cast's input expression includes an
>> explicit COLLATE clause.
>
>
On Mar 26, 2011, at 12:36 AM, Tom Lane wrote:
> ** Selecting a field from a record-returning function's output.
> Currently, we'll use the field's declared collation; except that
> if the field has default collation, we'll replace that with the common
> collation of the function's inputs, if any.
On Sat, Mar 26, 2011 at 4:36 AM, Tom Lane wrote:
> ** Selecting a field from a record-returning function's output.
> Currently, we'll use the field's declared collation; except that
> if the field has default collation, we'll replace that with the common
> collation of the function's inputs, if an
On Sat, Mar 26, 2011 at 4:36 AM, Tom Lane wrote:
> Robert Haas writes:
>> I think some discussion of which of the things on the open
>> item lists need to be done before beta might be helpful, and we ought
>> to add any items that are not there but are blockers.
>
> Here's a quick enumeration of
Robert Haas writes:
> I think some discussion of which of the things on the open
> item lists need to be done before beta might be helpful, and we ought
> to add any items that are not there but are blockers.
Here's a quick enumeration of some things I think need discussion about
the collations p
25 matches
Mail list logo
