On Thu, 2020-01-16 at 16:50 +, Richard van der Hoff wrote:
> I'm trying to track down the cause of some duplicate rows in a table
> which I would expect to be impossible due to a unique constraint. I'm
> hoping that somebody here will be able to suggest something I might have
> missed.
>
>
That's why I created a virtual_string function to squeeze out everything
but alpha characters and numbers 0-9 from any varchar or text columns
that I want to use as business key columns. For example, if I have a
column named job_name, I will have a companion column named v_job_name.
The v_ co
On 16/01/2020 17:48, Tom Lane wrote:
Richard van der Hoff writes:
On 16/01/2020 17:12, Magnus Hagander wrote:
See https://wiki.postgresql.org/wiki/Locale_data_changes for hints on
which linux distros updated when.
It seems like a plausible explanation but it's worth noting that all the
inde
Richard van der Hoff writes:
> On 16/01/2020 17:12, Magnus Hagander wrote:
>> See https://wiki.postgresql.org/wiki/Locale_data_changes for hints on
>> which linux distros updated when.
> It seems like a plausible explanation but it's worth noting that all the
> indexed data here is (despite bein
On 16/01/2020 17:27, Adrian Klaver wrote:
On 1/16/20 9:24 AM, Richard van der Hoff wrote:
It seems like a plausible explanation but it's worth noting that all
the indexed data here is (despite being in text columns), plain ascii.
I'm surprised that a change in collation rules would change the
On 16/01/2020 17:24, Daniel Verite wrote:
Looking at these columns which are of type text but do not
contain words of any particular language, there's probably
no point in using a linguistic-aware collation for them.
If you maintain the database schema, what you could do to avoid
the dependen
On 1/16/20 9:24 AM, Richard van der Hoff wrote:
On 16/01/2020 17:12, Magnus Hagander wrote:
On Thu, Jan 16, 2020 at 6:08 PM Tom Lane wrote:
Richard van der Hoff writes:
I'm trying to track down the cause of some duplicate rows in a table
which I would expect to be impossible due to a uniqu
Richard van der Hoff wrote:
> synapse=> select count(*), room_id, type, state_key from
> current_state_events group by 2,3,4 order by count(*) DESC LIMIT 2;
> count | room_id | type | state_key
> ---+---+---
On 16/01/2020 17:12, Magnus Hagander wrote:
On Thu, Jan 16, 2020 at 6:08 PM Tom Lane wrote:
Richard van der Hoff writes:
I'm trying to track down the cause of some duplicate rows in a table
which I would expect to be impossible due to a unique constraint. I'm
hoping that somebody here will
On Thu, Jan 16, 2020 at 6:08 PM Tom Lane wrote:
>
> Richard van der Hoff writes:
> > I'm trying to track down the cause of some duplicate rows in a table
> > which I would expect to be impossible due to a unique constraint. I'm
> > hoping that somebody here will be able to suggest something I mig
Richard van der Hoff wrote:
> So, question: what could we be doing wrong to get ourselves into this
> situation?
OS/libc upgrades without reindexing come to mind.
See https://wiki.postgresql.org/wiki/Collations
> * At least one user reports that he has recently migrated his database
>
Richard van der Hoff writes:
> I'm trying to track down the cause of some duplicate rows in a table
> which I would expect to be impossible due to a unique constraint. I'm
> hoping that somebody here will be able to suggest something I might have
> missed.
Since these are text columns, one pos
On 1/16/20 8:50 AM, Richard van der Hoff wrote:
I'm trying to track down the cause of some duplicate rows in a table
which I would expect to be impossible due to a unique constraint. I'm
hoping that somebody here will be able to suggest something I might have
missed.
The problem relates to a
I'm trying to track down the cause of some duplicate rows in a table
which I would expect to be impossible due to a unique constraint. I'm
hoping that somebody here will be able to suggest something I might have
missed.
The problem relates to a bug filed against our application
(https://githu
14 matches
Mail list logo
