On sön, 2011-03-13 at 13:16 -0400, Tom Lane wrote:
> Well, it's exactly that distinction that's bugging me. It seems a bit
> arbitrary if collation propagates in certain cases where collation
> state doesn't. I'm concerned in particular that we're going to find
> ourselves backend into a corner i
On 12.03.2011 18:17, Tom Lane wrote:
Does the SQL
standard have anything to say on the matter, or is there a precedent in
the behavior of TSQL or other DBMSes?
Tom,
SQL standard let it open for implementers.
The other DBMS - for which I am/was collation expert - takes afair the
database/sc
On Sun, Mar 13, 2011 at 01:16:36PM -0400, Tom Lane wrote:
> > I said don't propegate the collation *state*, the collation should be
> > propegated.
>
> Well, it's exactly that distinction that's bugging me. It seems a bit
> arbitrary if collation propagates in certain cases where collation state
On Mar 13, 2011, at 8:25 AM, Martijn van Oosterhout wrote:
> What you're suggesting is going to lead to situations where the user
> sets a non-default collation on every field in every table in the
> database and depending on the query they will sometimes get the default
> collation anyway.
Not t
Martijn van Oosterhout writes:
> On Sat, Mar 12, 2011 at 06:06:33PM -0500, Tom Lane wrote:
>> I remain unconvinced, because there are too many corner cases. Should
>> collation propagate up out of a subselect? How about a CTE? You're
>> starting to get into some pretty weird action-at-a-distanc
On Sat, Mar 12, 2011 at 06:06:33PM -0500, Tom Lane wrote:
> I remain unconvinced, because there are too many corner cases. Should
> collation propagate up out of a subselect? How about a CTE? You're
> starting to get into some pretty weird action-at-a-distance situations
> if so, analogous to th
Martijn van Oosterhout writes:
> On Sat, Mar 12, 2011 at 02:46:19PM -0500, Tom Lane wrote:
>> This would actually seem more sensible if we went with something even
>> simpler than the current patch's behavior, namely that COLLATE only
>> affects the operator it is an *immediate* input of, and noth
Martijn van Oosterhout writes:
> I think I didn't explain myself well. The *state* should be implicit,
> the actual collation should be whatever the query says. What I was
> thinking of is the following:
> CREATE FUNCTION my_english_lt(text, text) RETURNS boolean AS $$
>return $1 < $2 COLLATE
On Sat, Mar 12, 2011 at 02:46:19PM -0500, Tom Lane wrote:
> > Similarly, inside the function the parameters should be considered to
> > be IMPLICIT collation, to avoid strange errors depending on how its
> > called.
>
> Not convinced by this. If we say that that's how it works, then no
> user-def
On lör, 2011-03-12 at 12:17 -0500, Tom Lane wrote:
> Does the SQL standard have anything to say on the matter, or is there
> a precedent in the behavior of TSQL or other DBMSes?
I had investigated this issue but the SQL standard doesn't say anything
about it.
The SQL inlining issue is tricky. Ot
Martijn van Oosterhout writes:
> On Sat, Mar 12, 2011 at 12:17:11PM -0500, Tom Lane wrote:
>> I've thought of another area that AFAICT the current patch fails to
>> address at all: what should happen in user-defined functions?
> The POLA suggests that the collation derivation of the original quer
Greg Stark writes:
> On Sat, Mar 12, 2011 at 5:17 PM, Tom Lane wrote:
>>create function my_lt(x text, y text) returns bool as
>>$
>>begin
>>return x < y;
>>end
>>$ language plpgsql;
>>
>>select my_lt('foo', '
On Sat, Mar 12, 2011 at 5:17 PM, Tom Lane wrote:
> create function my_lt(x text, y text) returns bool as
> $
> begin
> return x < y;
> end
> $ language plpgsql;
>
> select my_lt('foo', 'bar' collate "de_DE");
>
On Sat, Mar 12, 2011 at 12:17:11PM -0500, Tom Lane wrote:
> I've thought of another area that AFAICT the current patch fails to
> address at all: what should happen in user-defined functions?
The POLA suggests that the collation derivation of the original query
should not be affected by the impl
I've thought of another area that AFAICT the current patch fails to
address at all: what should happen in user-defined functions?
Consider
create function my_lt(x text, y text) returns bool as
$$
begin
return x < y;
end
15 matches
Mail list logo
