Christian Barthel writes:
> On Thursday, July 21, 2022, Adrian Klaver wrote:
>> Why does it matter?
> As the comment in pg_dump.c states, logically identical schemas should
> produce identical dumps:
Agreed, but this is far from the only deficiency in DOTypeNameCompare.
If we're going to try to
On 7/21/22 10:59, Christian Barthel wrote:
On Thursday, July 21, 2022, Adrian Klaver wrote:
Why does it matter?
As the comment in pg_dump.c states, logically identical schemas should
produce identical dumps:
| * We rely on dependency information to help us determine a safe order,
| so * the
On Thursday, July 21, 2022, Adrian Klaver wrote:
> On 7/21/22 10:25, Christian Barthel wrote:
>> Hello, The sorting order of FK constraints with the same name is
>> based on the OID (because it lands in the “Usually shouldn’t get
>> here” OID comparison block at [1]). Wouldn’t it be better if the
gt; > block at [1]). Wouldn’t it be better if the order of those constraints
> > were based on the table name?
> >
>
> Why does it matter?
>
>
As the code comment says:
/* To have a stable sort order, break ties for some object types */
This seems like it is simply a missed case.
David J.
On 7/21/22 10:25, Christian Barthel wrote:
Hello,
The sorting order of FK constraints with the same name is based on the
OID (because it lands in the “Usually shouldn’t get here” OID comparison
block at [1]). Wouldn’t it be better if the order of those constraints
were based on the table name?
Hello,
The sorting order of FK constraints with the same name is based on the
OID (because it lands in the “Usually shouldn’t get here” OID comparison
block at [1]). Wouldn’t it be better if the order of those constraints
were based on the table name?
Details:
The above schema is identical exce
Matthias Apitz writes:
> Said that, does the SORT done by the server depends on the environment
> (LANG, LC_*) in which the PostgreSQL server is started or only of the
> sp_catalog information of the database in question?
We set LC_COLLATE and LC_CTYPE from the database's relevant
pg_database fie
El día Donnerstag, Februar 03, 2022 a las 10:00:37 -0500, Tom Lane escribió:
> Matthias Apitz writes:
> > El día jueves, febrero 03, 2022 a las 11:14:55 +0100, Matthias Apitz
> > escribió:
> >> With ESQL/C on a PostgreSQL 13.1 server I see the result of this query:
> >> select katkey,normform fr
On Fri, Feb 4, 2022 at 8:11 AM Matthias Apitz wrote:
> On my FreeBSD laptop the same file sorts as
>
> guru@c720-r368166:~ $ LANG=de_DE.UTF-8 sort swd
> A
> ゲアハルト・A・リッター
> ゲルハルト・A・リッター
> チャールズ・A・ビアード
> A010STRUKTUR
> A010STRUKTUR
> A010STRUKTUR
> A0150SUPRALEITER
Wow, so it's one thing to have a
El día jueves, febrero 03, 2022 a las 10:00:37 -0500, Tom Lane escribió:
> Matthias Apitz writes:
> > El día jueves, febrero 03, 2022 a las 11:14:55 +0100, Matthias Apitz
> > escribió:
> >> With ESQL/C on a PostgreSQL 13.1 server I see the result of this query:
> >> select katkey,normform from s
Matthias Apitz writes:
> El día jueves, febrero 03, 2022 a las 11:14:55 +0100, Matthias Apitz escribió:
>> With ESQL/C on a PostgreSQL 13.1 server I see the result of this query:
>> select katkey,normform from swd_anzeige where normform >= 'A' ORDER BY ASC;
>> coming out in this order:
>> ...
>> I
El día jueves, febrero 03, 2022 a las 11:14:55 +0100, Matthias Apitz escribió:
>
> Hello,
>
> With ESQL/C on a PostgreSQL 13.1 server I see the result of this query:
>
> select katkey,normform from swd_anzeige where normform >= 'A' ORDER BY ASC;
>
> coming out in this order:
>
> query: fetch
Hello,
With ESQL/C on a PostgreSQL 13.1 server I see the result of this query:
select katkey,normform from swd_anzeige where normform >= 'A' ORDER BY ASC;
coming out in this order:
query: fetch swd_anzeige_seq
RESULT: A
query: fetch swd_anzeige_seq
RESULT: ゲアハルト・A・リッター
query: fetch swd_anzeig
On 27.07.21 19:07, Marc Millas wrote:
so, obviously, both lc_collate knows about the é
but obviously, too, they do behave differently on the impact of the
beginning white space.
I didn't see anything about this behaviour on the doc, unless the
reference at the libc should be understood as ple
Marc Millas writes:
> Re-reading my post, I see that even the élise is not sorted correctly on
> w10...
Sort orders aren't even particularly guaranteed on different releases
of the same platform, let alone totally different platforms. glibc
made major changes to their collation rules not long ag
Re-reading my post, I see that even the élise is not sorted correctly on
w10...
Marc MILLAS
Senior Architect
+33607850334
www.mokadb.com
On Tue, Jul 27, 2021 at 7:07 PM Marc Millas wrote:
> Hi,
>
> context:
> one postgres 12 on centos 7
> one postgres 12 on windows 10
> both on machines with
Hi,
context:
one postgres 12 on centos 7
one postgres 12 on windows 10
both on machines with french as default
the centos 7 lc_collate and lc_ctype: fr_FR.UTF_8
the w10 lc_collate and lc_ctype: French_France.1252
create table test (ble text, id serial primary key);
insert into test(ble) values('
On Wed, 12 Feb 2020, 19:55 Laurenz Albe, wrote:
> On Wed, 2020-02-12 at 18:45 +0300, Dmitry Igrishin wrote:
> > I've implemented a PostgreSQL extension for natural sort order. I.e.
> > strings like "z20", "z0004", "z11", "z2"
On Wed, 2020-02-12 at 18:45 +0300, Dmitry Igrishin wrote:
> I've implemented a PostgreSQL extension for natural sort order. I.e.
> strings like "z20", "z0004", "z11", "z2" sorted in ascending order as
> "z2", "z0004", &
Hi,
I've implemented a PostgreSQL extension for natural sort order. I.e.
strings like "z20", "z0004", "z11", "z2" sorted in ascending order as
"z2", "z0004", "z11", "z20".
Currently it implements the type te
20 matches
Mail list logo
