Re: Collations versus user-defined functions

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Collations versus user-defined functions
Date: 2011-03-13 21:16:40
Message-ID: 20110313211640.GC16472@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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
> doesn't. I'm concerned in particular that we're going to find ourselves
> backend into a corner if someone comes up with a different reading of
> the spec. The proposed implementation will be incapable of propagating
> collation state across subselect boundaries (because the post-parse scan
> is going to operate at most one subquery at a time), so if someone
> convinces us that we should do that, what then?

Hmm, if you suggest the proposed implementation won't do it then I
believe you. I would have thought it could be propegated at the same
time as the type information, after all the SQL standard considers the
collation to be part of the SQL type (like Robert says you have lots of
closely related character types, section 4.2.1).

The reason you don't want to transport collation state across
boundaries is because it makes things go action-at-a-distance, like you
say. It is the collation states that control the propegation.

The only guidence I can find on this in the SQL standard (since AFAICS
neither MySQL nor Transact-SQL describe this clearly in their
documentation) is section 4.2.2 and it says that anything with a
declared data type is implicit. So function arguments, table columns
and the like are implicit. Everything else is by definition derived
(after all the type must also be derived).

So I'd suggest that collate state EXPLICIT only propegates within the
same scope where its visible what its doing, and is only assumed
implicit when it hits a point where the datatype is stored, like views,
functions, etc. That's my reading of it anyway.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patriotism is when love of your own people comes first; nationalism,
> when hate for people other than your own comes first.
> - Charles de Gaulle

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nikhil Sontakke 2011-03-13 23:34:05 Re: Fwd: index corruption in PG 8.3.13
Previous Message Dmitriy Igrishin 2011-03-13 18:44:15 Multi-language glossary of PostgreSQL terms.