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 if
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
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 the
Martijn van Oosterhout klep...@svana.org 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
On Mar 13, 2011, at 8:25 AM, Martijn van Oosterhout klep...@svana.org 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
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
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
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?
snip
The POLA suggests that the collation derivation of the original query
should not be affected by the
On Sat, Mar 12, 2011 at 5:17 PM, Tom Lane t...@sss.pgh.pa.us 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);
Greg Stark gsst...@mit.edu writes:
On Sat, Mar 12, 2011 at 5:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
create function my_lt(x text, y text) returns bool as
$
begin
return x y;
end
$ language plpgsql;
Martijn van Oosterhout klep...@svana.org 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
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.
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-defined
Martijn van Oosterhout klep...@svana.org 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
Martijn van Oosterhout klep...@svana.org 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
15 matches
Mail list logo
