fixes for the Danish locale
In Danish, the sequence 'aa' is sometimes treated as a single letter
which collates after 'z'.
Some regression tests got into 9.5, and are still in 9.6beta3, which
fail due to assuming they know how things will sort or compare.
I thought the easiest way to deal with it was just to change the test
data to use 'ab...' rather than 'aa...' to represent an
early-collating string.
With these applied, this now passes:
LANG=danish make check
Cheers,
Jeff
Attachments:
danish_brin.patchapplication/octet-stream; name=danish_brin.patchDownload
diff --git a/src/test/regress/expected/brin.out b/src/test/regress/expected/brin.out
new file mode 100644
index 4755259..21676e5
*** a/src/test/regress/expected/brin.out
--- b/src/test/regress/expected/brin.out
*************** INSERT INTO brinopers VALUES
*** 149,155 ****
'{100, 100, 1, 100, 100}'),
('textcol', 'text',
'{>, >=, =, <=, <}',
! '{AAAAAA, AAAAAA, BNAAAABNAAAABNAAAABNAAAABNAAAABNAAAABNAAAABNAAAA, ZZAAAA, ZZAAAA}',
'{100, 100, 1, 100, 100}'),
('oidcol', 'oid',
'{>, >=, =, <=, <}',
--- 149,155 ----
'{100, 100, 1, 100, 100}'),
('textcol', 'text',
'{>, >=, =, <=, <}',
! '{ABABAB, ABABAB, BNAAAABNAAAABNAAAABNAAAABNAAAABNAAAABNAAAABNAAAA, ZZAAAA, ZZAAAA}',
'{100, 100, 1, 100, 100}'),
('oidcol', 'oid',
'{>, >=, =, <=, <}',
diff --git a/src/test/regress/sql/brin.sql b/src/test/regress/sql/brin.sql
new file mode 100644
index 9e4836e..e7f6f77
*** a/src/test/regress/sql/brin.sql
--- b/src/test/regress/sql/brin.sql
*************** INSERT INTO brinopers VALUES
*** 154,160 ****
'{100, 100, 1, 100, 100}'),
('textcol', 'text',
'{>, >=, =, <=, <}',
! '{AAAAAA, AAAAAA, BNAAAABNAAAABNAAAABNAAAABNAAAABNAAAABNAAAABNAAAA, ZZAAAA, ZZAAAA}',
'{100, 100, 1, 100, 100}'),
('oidcol', 'oid',
'{>, >=, =, <=, <}',
--- 154,160 ----
'{100, 100, 1, 100, 100}'),
('textcol', 'text',
'{>, >=, =, <=, <}',
! '{ABABAB, ABABAB, BNAAAABNAAAABNAAAABNAAAABNAAAABNAAAABNAAAABNAAAA, ZZAAAA, ZZAAAA}',
'{100, 100, 1, 100, 100}'),
('oidcol', 'oid',
'{>, >=, =, <=, <}',
danish_row_level_security.patchapplication/octet-stream; name=danish_row_level_security.patchDownload
diff --git a/src/test/regress/expected/rowsecurity.out b/src/test/regress/expected/rowsecurity.out
new file mode 100644
index 35541ce..14495ef
*** a/src/test/regress/expected/rowsecurity.out
--- b/src/test/regress/expected/rowsecurity.out
*************** EXPLAIN (COSTS OFF) SELECT a, b, oid FRO
*** 664,670 ****
RESET SESSION AUTHORIZATION;
SET row_security TO OFF;
SELECT * FROM t1 WHERE f_leak(b);
! NOTICE: f_leak => aaa
NOTICE: f_leak => bbb
NOTICE: f_leak => ccc
NOTICE: f_leak => ddd
--- 664,670 ----
RESET SESSION AUTHORIZATION;
SET row_security TO OFF;
SELECT * FROM t1 WHERE f_leak(b);
! NOTICE: f_leak => aba
NOTICE: f_leak => bbb
NOTICE: f_leak => ccc
NOTICE: f_leak => ddd
*************** NOTICE: f_leak => yyy
*** 677,683 ****
NOTICE: f_leak => zzz
a | b
---+-----
! 1 | aaa
2 | bbb
3 | ccc
4 | ddd
--- 677,683 ----
NOTICE: f_leak => zzz
a | b
---+-----
! 1 | aba
2 | bbb
3 | ccc
4 | ddd
*************** EXPLAIN (COSTS OFF) SELECT * FROM t1 WHE
*** 706,712 ****
SET SESSION AUTHORIZATION regress_rls_exempt_user;
SET row_security TO OFF;
SELECT * FROM t1 WHERE f_leak(b);
! NOTICE: f_leak => aaa
NOTICE: f_leak => bbb
NOTICE: f_leak => ccc
NOTICE: f_leak => ddd
--- 706,712 ----
SET SESSION AUTHORIZATION regress_rls_exempt_user;
SET row_security TO OFF;
SELECT * FROM t1 WHERE f_leak(b);
! NOTICE: f_leak => aba
NOTICE: f_leak => bbb
NOTICE: f_leak => ccc
NOTICE: f_leak => ddd
*************** NOTICE: f_leak => yyy
*** 719,725 ****
NOTICE: f_leak => zzz
a | b
---+-----
! 1 | aaa
2 | bbb
3 | ccc
4 | ddd
--- 719,725 ----
NOTICE: f_leak => zzz
a | b
---+-----
! 1 | aba
2 | bbb
3 | ccc
4 | ddd
*************** EXPLAIN (COSTS OFF) EXECUTE p1(2);
*** 952,958 ****
RESET SESSION AUTHORIZATION;
SET row_security TO OFF;
SELECT * FROM t1 WHERE f_leak(b);
! NOTICE: f_leak => aaa
NOTICE: f_leak => bbb
NOTICE: f_leak => ccc
NOTICE: f_leak => ddd
--- 952,958 ----
RESET SESSION AUTHORIZATION;
SET row_security TO OFF;
SELECT * FROM t1 WHERE f_leak(b);
! NOTICE: f_leak => aba
NOTICE: f_leak => bbb
NOTICE: f_leak => ccc
NOTICE: f_leak => ddd
*************** NOTICE: f_leak => yyy
*** 965,971 ****
NOTICE: f_leak => zzz
a | b
---+-----
! 1 | aaa
2 | bbb
3 | ccc
4 | ddd
--- 965,971 ----
NOTICE: f_leak => zzz
a | b
---+-----
! 1 | aba
2 | bbb
3 | ccc
4 | ddd
*************** EXPLAIN (COSTS OFF) SELECT * FROM t1 WHE
*** 994,1000 ****
EXECUTE p1(2);
a | b
---+-----
! 1 | aaa
2 | bbb
1 | abc
2 | bcd
--- 994,1000 ----
EXECUTE p1(2);
a | b
---+-----
! 1 | aba
2 | bbb
1 | abc
2 | bcd
*************** SET row_security TO OFF;
*** 1345,1351 ****
SELECT * FROM t1 ORDER BY a,b;
a | b
---+-------------
! 1 | aaa
1 | abc
1 | xxx
2 | bbbbbb_updt
--- 1345,1351 ----
SELECT * FROM t1 ORDER BY a,b;
a | b
---+-------------
! 1 | aba
1 | abc
1 | xxx
2 | bbbbbb_updt
*************** CREATE TABLE z2 (a int, b text);
*** 1653,1659 ****
GRANT SELECT ON z1,z2 TO regress_rls_group1, regress_rls_group2,
regress_rls_bob, regress_rls_carol;
INSERT INTO z1 VALUES
! (1, 'aaa'),
(2, 'bbb'),
(3, 'ccc'),
(4, 'ddd');
--- 1653,1659 ----
GRANT SELECT ON z1,z2 TO regress_rls_group1, regress_rls_group2,
regress_rls_bob, regress_rls_carol;
INSERT INTO z1 VALUES
! (1, 'aba'),
(2, 'bbb'),
(3, 'ccc'),
(4, 'ddd');
*************** EXPLAIN (COSTS OFF) EXECUTE plancache_te
*** 1777,1787 ****
SET SESSION AUTHORIZATION regress_rls_carol;
SELECT * FROM z1 WHERE f_leak(b);
! NOTICE: f_leak => aaa
NOTICE: f_leak => ccc
a | b
---+-----
! 1 | aaa
3 | ccc
(2 rows)
--- 1777,1787 ----
SET SESSION AUTHORIZATION regress_rls_carol;
SELECT * FROM z1 WHERE f_leak(b);
! NOTICE: f_leak => aba
NOTICE: f_leak => ccc
a | b
---+-----
! 1 | aba
3 | ccc
(2 rows)
*************** EXPLAIN (COSTS OFF) EXECUTE plancache_te
*** 1833,1843 ****
SET ROLE regress_rls_group2;
SELECT * FROM z1 WHERE f_leak(b);
! NOTICE: f_leak => aaa
NOTICE: f_leak => ccc
a | b
---+-----
! 1 | aaa
3 | ccc
(2 rows)
--- 1833,1843 ----
SET ROLE regress_rls_group2;
SELECT * FROM z1 WHERE f_leak(b);
! NOTICE: f_leak => aba
NOTICE: f_leak => ccc
a | b
---+-----
! 1 | aba
3 | ccc
(2 rows)
*************** GRANT SELECT ON rls_view TO regress_rls_
*** 1897,1909 ****
-- Query as role that is not owner of view or table. Should return all records.
SET SESSION AUTHORIZATION regress_rls_bob;
SELECT * FROM rls_view;
! NOTICE: f_leak => aaa
NOTICE: f_leak => bbb
NOTICE: f_leak => ccc
NOTICE: f_leak => ddd
a | b
---+-----
! 1 | aaa
2 | bbb
3 | ccc
4 | ddd
--- 1897,1909 ----
-- Query as role that is not owner of view or table. Should return all records.
SET SESSION AUTHORIZATION regress_rls_bob;
SELECT * FROM rls_view;
! NOTICE: f_leak => aba
NOTICE: f_leak => bbb
NOTICE: f_leak => ccc
NOTICE: f_leak => ddd
a | b
---+-----
! 1 | aba
2 | bbb
3 | ccc
4 | ddd
*************** EXPLAIN (COSTS OFF) SELECT * FROM rls_vi
*** 1919,1931 ****
-- Query as view/table owner. Should return all records.
SET SESSION AUTHORIZATION regress_rls_alice;
SELECT * FROM rls_view;
! NOTICE: f_leak => aaa
NOTICE: f_leak => bbb
NOTICE: f_leak => ccc
NOTICE: f_leak => ddd
a | b
---+-----
! 1 | aaa
2 | bbb
3 | ccc
4 | ddd
--- 1919,1931 ----
-- Query as view/table owner. Should return all records.
SET SESSION AUTHORIZATION regress_rls_alice;
SELECT * FROM rls_view;
! NOTICE: f_leak => aba
NOTICE: f_leak => bbb
NOTICE: f_leak => ccc
NOTICE: f_leak => ddd
a | b
---+-----
! 1 | aba
2 | bbb
3 | ccc
4 | ddd
diff --git a/src/test/regress/sql/rowsecurity.sql b/src/test/regress/sql/rowsecurity.sql
new file mode 100644
index a142923..785ac84
*** a/src/test/regress/sql/rowsecurity.sql
--- b/src/test/regress/sql/rowsecurity.sql
*************** ALTER TABLE t1 DROP COLUMN junk1; --
*** 200,206 ****
GRANT ALL ON t1 TO public;
COPY t1 FROM stdin WITH (oids);
! 101 1 aaa
102 2 bbb
103 3 ccc
104 4 ddd
--- 200,206 ----
GRANT ALL ON t1 TO public;
COPY t1 FROM stdin WITH (oids);
! 101 1 aba
102 2 bbb
103 3 ccc
104 4 ddd
*************** GRANT SELECT ON z1,z2 TO regress_rls_gro
*** 635,641 ****
regress_rls_bob, regress_rls_carol;
INSERT INTO z1 VALUES
! (1, 'aaa'),
(2, 'bbb'),
(3, 'ccc'),
(4, 'ddd');
--- 635,641 ----
regress_rls_bob, regress_rls_carol;
INSERT INTO z1 VALUES
! (1, 'aba'),
(2, 'bbb'),
(3, 'ccc'),
(4, 'ddd');
Jeff Janes <jeff.janes@gmail.com> writes:
In Danish, the sequence 'aa' is sometimes treated as a single letter
which collates after 'z'.
Some regression tests got into 9.5, and are still in 9.6beta3, which
fail due to assuming they know how things will sort or compare.
Confirmed here. Will deal with it, but I wonder why we have no buildfarm
members covering this ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jul 21, 2016 at 5:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Confirmed here. Will deal with it, but I wonder why we have no buildfarm
members covering this ...
We're not going to have a build farm member for every locale the local
systems support.
Perhaps the build farm script should pick a random locale for each
run. Either a random locale from the set on the OS or a random
language from a list of locale that the regression tests are intended
to be safe for.
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jul 21, 2016 at 11:26 AM, Greg Stark <stark@mit.edu> wrote:
Perhaps the build farm script should pick a random locale for each
run. Either a random locale from the set on the OS or a random
language from a list of locale that the regression tests are intended
to be safe for.
That's more or less what I did with the amcheck regression tests.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Greg Stark <stark@mit.edu> writes:
On Thu, Jul 21, 2016 at 5:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Confirmed here. Will deal with it, but I wonder why we have no buildfarm
members covering this ...
We're not going to have a build farm member for every locale the local
systems support.
Probably not, but Danish seems odd enough to be worth testing. Aside
from this issue, I found one in the pltcl tests.
Perhaps the build farm script should pick a random locale for each
run. Either a random locale from the set on the OS or a random
language from a list of locale that the regression tests are intended
to be safe for.
Nah, we have a hard enough time with reproducibility of buildfarm results
without deliberately injecting transient failures.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jul 21, 2016 at 11:29 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Perhaps the build farm script should pick a random locale for each
run. Either a random locale from the set on the OS or a random
language from a list of locale that the regression tests are intended
to be safe for.Nah, we have a hard enough time with reproducibility of buildfarm results
without deliberately injecting transient failures.
It could be pseudo-random, and so deterministic per buildfarm animal.
That's what I did.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Peter Geoghegan <pg@heroku.com> writes:
On Thu, Jul 21, 2016 at 11:29 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Nah, we have a hard enough time with reproducibility of buildfarm results
without deliberately injecting transient failures.
It could be pseudo-random, and so deterministic per buildfarm animal.
That's what I did.
I'm not impressed with that proposal either --- then we don't even have
any control over what set of locales are getting tested.
Note that there are certain locales we've deliberately chosen not to
support in some regression tests (see e.g. plpython_unicode.sql), so
I'm not really willing to buy into the idea that "any random locale found
on a buildfarm animal should work" anyway. I'm much more interested in
supporting locales that someone cares enough about to configure a
buildfarm animal for.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jul 21, 2016 at 9:44 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Jeff Janes <jeff.janes@gmail.com> writes:
In Danish, the sequence 'aa' is sometimes treated as a single letter
which collates after 'z'.
Some regression tests got into 9.5, and are still in 9.6beta3, which
fail due to assuming they know how things will sort or compare.Confirmed here. Will deal with it, but I wonder why we have no buildfarm
members covering this ...
My CentOS box came with 735 locales installed, so testing all of them
on a regular basis would be quite a task. And it doesn't help that
many of them seem to be very slow compared to C locale.
I guess the good news is that nothing I tested which was working in
9.5 is broken in 9.6, but several things which were working in 9.4 did
get broken in 9.5 and still are in 9.6.
The Danish fix will probably also fix the (very large) Norwegian family.
The Welsh (cy_GB) apparently put 'dd' after 'f', which breaks row
level security in much the same way as 'aa' does.
I think that that will cover all of the ones that were working in 9.4.
Does testing in other locales ever uncover bugs other than those in
the tests themselves? Is it worth trying to maintain broad coverage?
Cheers,
Jeff
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jul 21, 2016 at 11:44 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Note that there are certain locales we've deliberately chosen not to
support in some regression tests (see e.g. plpython_unicode.sql), so
I'm not really willing to buy into the idea that "any random locale found
on a buildfarm animal should work" anyway. I'm much more interested in
supporting locales that someone cares enough about to configure a
buildfarm animal for.
That seems like a high standard to me. Locale rules are known to
change, and are explicitly versioned by glibc, for example.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jul 21, 2016 at 11:49 AM, Jeff Janes <jeff.janes@gmail.com> wrote:
Does testing in other locales ever uncover bugs other than those in
the tests themselves? Is it worth trying to maintain broad coverage?
Potentially, yes. The strxfrm() inconsistency issue disproportionately
affected de_DE.utf8, for example. There were other locales that were
affected less severely, and I think the majority were not shown to be
affected at all.
That being said, it probably wouldn't have caught that particular
issue if we had broad coverage. It probably would catch a broken test,
though.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 07/21/2016 02:26 PM, Greg Stark wrote:
On Thu, Jul 21, 2016 at 5:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Confirmed here. Will deal with it, but I wonder why we have no buildfarm
members covering this ...We're not going to have a build farm member for every locale the local
systems support.Perhaps the build farm script should pick a random locale for each
run. Either a random locale from the set on the OS or a random
language from a list of locale that the regression tests are intended
to be safe for.
I don't see why we shouldn't have a buildfarm machine that tests a very
large number of locales. It takes a very lightly resourced machine like
nightjar just over two minutes per locale. The list of locales to test
is a setting in the config file.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Jeff Janes <jeff.janes@gmail.com> writes:
In Danish, the sequence 'aa' is sometimes treated as a single letter
which collates after 'z'.
Some regression tests got into 9.5, and are still in 9.6beta3, which
fail due to assuming they know how things will sort or compare.
As of HEAD, "LANG=danish make check-world" passes for me, which it
did not before the round of fixes I just pushed.
I see that the core tests fall over in Turkish still :-(
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jul 21, 2016 at 2:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Jeff Janes <jeff.janes@gmail.com> writes:
In Danish, the sequence 'aa' is sometimes treated as a single letter
which collates after 'z'.
Some regression tests got into 9.5, and are still in 9.6beta3, which
fail due to assuming they know how things will sort or compare.As of HEAD, "LANG=danish make check-world" passes for me, which it
did not before the round of fixes I just pushed.I see that the core tests fall over in Turkish still :-(
Turkish has never passed (at least back to 9.0). It looks like it is
in the stemming functions. I don't understand why, I would think
everything other than English would be failing those if the regression
tests hard-code English stemming expectations but fail to arrange for
English stemming rules.
Cheers,
Jeff
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Jeff Janes <jeff.janes@gmail.com> writes:
On Thu, Jul 21, 2016 at 2:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I see that the core tests fall over in Turkish still :-(
Turkish has never passed (at least back to 9.0). It looks like it is
in the stemming functions. I don't understand why, I would think
everything other than English would be failing those if the regression
tests hard-code English stemming expectations but fail to arrange for
English stemming rules.
It looks to me like the 'simple' dictionary assumes it can apply the
lowercasing rules implied by LC_CTYPE regardless of which language
it's supposedly working on. This is probably something we should
improve sometime, but I doubt it's an easy change.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jul 21, 2016 at 11:49 AM, Jeff Janes <jeff.janes@gmail.com> wrote:
On Thu, Jul 21, 2016 at 9:44 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Jeff Janes <jeff.janes@gmail.com> writes:
In Danish, the sequence 'aa' is sometimes treated as a single letter
which collates after 'z'.
Some regression tests got into 9.5, and are still in 9.6beta3, which
fail due to assuming they know how things will sort or compare.Confirmed here. Will deal with it, but I wonder why we have no buildfarm
members covering this ...My CentOS box came with 735 locales installed, so testing all of them
on a regular basis would be quite a task. And it doesn't help that
many of them seem to be very slow compared to C locale.I guess the good news is that nothing I tested which was working in
9.5 is broken in 9.6, but several things which were working in 9.4 did
get broken in 9.5 and still are in 9.6.The Danish fix will probably also fix the (very large) Norwegian family.
The Welsh (cy_GB) apparently put 'dd' after 'f', which breaks row
level security in much the same way as 'aa' does.I think that that will cover all of the ones that were working in 9.4.
The attached patch fixes regression tests for Welsh (cy_GB), needed in
9.5 and 9.6.
Cheers,
Jeff
Attachments:
welsh_rowlevel.patchapplication/octet-stream; name=welsh_rowlevel.patchDownload
diff --git a/src/test/regress/expected/rowsecurity.out b/src/test/regress/expected/rowsecurity.out
new file mode 100644
index 14495ef..c15bf95
*** a/src/test/regress/expected/rowsecurity.out
--- b/src/test/regress/expected/rowsecurity.out
*************** SELECT * FROM t1;
*** 488,494 ****
a | b
---+-----
2 | bbb
! 4 | ddd
2 | bcd
4 | def
2 | yyy
--- 488,494 ----
a | b
---+-----
2 | bbb
! 4 | dad
2 | bcd
4 | def
2 | yyy
*************** EXPLAIN (COSTS OFF) SELECT * FROM t1;
*** 508,521 ****
SELECT * FROM t1 WHERE f_leak(b);
NOTICE: f_leak => bbb
! NOTICE: f_leak => ddd
NOTICE: f_leak => bcd
NOTICE: f_leak => def
NOTICE: f_leak => yyy
a | b
---+-----
2 | bbb
! 4 | ddd
2 | bcd
4 | def
2 | yyy
--- 508,521 ----
SELECT * FROM t1 WHERE f_leak(b);
NOTICE: f_leak => bbb
! NOTICE: f_leak => dad
NOTICE: f_leak => bcd
NOTICE: f_leak => def
NOTICE: f_leak => yyy
a | b
---+-----
2 | bbb
! 4 | dad
2 | bcd
4 | def
2 | yyy
*************** SELECT oid, * FROM t1;
*** 540,546 ****
oid | a | b
-----+---+-----
102 | 2 | bbb
! 104 | 4 | ddd
202 | 2 | bcd
204 | 4 | def
302 | 2 | yyy
--- 540,546 ----
oid | a | b
-----+---+-----
102 | 2 | bbb
! 104 | 4 | dad
202 | 2 | bcd
204 | 4 | def
302 | 2 | yyy
*************** SELECT *, t1 FROM t1;
*** 563,569 ****
a | b | t1
---+-----+---------
2 | bbb | (2,bbb)
! 4 | ddd | (4,ddd)
2 | bcd | (2,bcd)
4 | def | (4,def)
2 | yyy | (2,yyy)
--- 563,569 ----
a | b | t1
---+-----+---------
2 | bbb | (2,bbb)
! 4 | dad | (4,dad)
2 | bcd | (2,bcd)
4 | def | (4,def)
2 | yyy | (2,yyy)
*************** SELECT * FROM t1 FOR SHARE;
*** 586,592 ****
a | b
---+-----
2 | bbb
! 4 | ddd
2 | bcd
4 | def
2 | yyy
--- 586,592 ----
a | b
---+-----
2 | bbb
! 4 | dad
2 | bcd
4 | def
2 | yyy
*************** EXPLAIN (COSTS OFF) SELECT * FROM t1 FOR
*** 610,623 ****
SELECT * FROM t1 WHERE f_leak(b) FOR SHARE;
NOTICE: f_leak => bbb
! NOTICE: f_leak => ddd
NOTICE: f_leak => bcd
NOTICE: f_leak => def
NOTICE: f_leak => yyy
a | b
---+-----
2 | bbb
! 4 | ddd
2 | bcd
4 | def
2 | yyy
--- 610,623 ----
SELECT * FROM t1 WHERE f_leak(b) FOR SHARE;
NOTICE: f_leak => bbb
! NOTICE: f_leak => dad
NOTICE: f_leak => bcd
NOTICE: f_leak => def
NOTICE: f_leak => yyy
a | b
---+-----
2 | bbb
! 4 | dad
2 | bcd
4 | def
2 | yyy
*************** SELECT * FROM t1 WHERE f_leak(b);
*** 667,673 ****
NOTICE: f_leak => aba
NOTICE: f_leak => bbb
NOTICE: f_leak => ccc
! NOTICE: f_leak => ddd
NOTICE: f_leak => abc
NOTICE: f_leak => bcd
NOTICE: f_leak => cde
--- 667,673 ----
NOTICE: f_leak => aba
NOTICE: f_leak => bbb
NOTICE: f_leak => ccc
! NOTICE: f_leak => dad
NOTICE: f_leak => abc
NOTICE: f_leak => bcd
NOTICE: f_leak => cde
*************** NOTICE: f_leak => zzz
*** 680,686 ****
1 | aba
2 | bbb
3 | ccc
! 4 | ddd
1 | abc
2 | bcd
3 | cde
--- 680,686 ----
1 | aba
2 | bbb
3 | ccc
! 4 | dad
1 | abc
2 | bcd
3 | cde
*************** SELECT * FROM t1 WHERE f_leak(b);
*** 709,715 ****
NOTICE: f_leak => aba
NOTICE: f_leak => bbb
NOTICE: f_leak => ccc
! NOTICE: f_leak => ddd
NOTICE: f_leak => abc
NOTICE: f_leak => bcd
NOTICE: f_leak => cde
--- 709,715 ----
NOTICE: f_leak => aba
NOTICE: f_leak => bbb
NOTICE: f_leak => ccc
! NOTICE: f_leak => dad
NOTICE: f_leak => abc
NOTICE: f_leak => bcd
NOTICE: f_leak => cde
*************** NOTICE: f_leak => zzz
*** 722,728 ****
1 | aba
2 | bbb
3 | ccc
! 4 | ddd
1 | abc
2 | bcd
3 | cde
--- 722,728 ----
1 | aba
2 | bbb
3 | ccc
! 4 | dad
1 | abc
2 | bcd
3 | cde
*************** SELECT * FROM t1 WHERE f_leak(b);
*** 955,961 ****
NOTICE: f_leak => aba
NOTICE: f_leak => bbb
NOTICE: f_leak => ccc
! NOTICE: f_leak => ddd
NOTICE: f_leak => abc
NOTICE: f_leak => bcd
NOTICE: f_leak => cde
--- 955,961 ----
NOTICE: f_leak => aba
NOTICE: f_leak => bbb
NOTICE: f_leak => ccc
! NOTICE: f_leak => dad
NOTICE: f_leak => abc
NOTICE: f_leak => bcd
NOTICE: f_leak => cde
*************** NOTICE: f_leak => zzz
*** 968,974 ****
1 | aba
2 | bbb
3 | ccc
! 4 | ddd
1 | abc
2 | bcd
3 | cde
--- 968,974 ----
1 | aba
2 | bbb
3 | ccc
! 4 | dad
1 | abc
2 | bcd
3 | cde
*************** EXPLAIN (COSTS OFF) UPDATE t1 SET b = b
*** 1088,1094 ****
UPDATE t1 SET b = b || b WHERE f_leak(b);
NOTICE: f_leak => bbb
! NOTICE: f_leak => ddd
NOTICE: f_leak => bcd
NOTICE: f_leak => def
NOTICE: f_leak => yyy
--- 1088,1094 ----
UPDATE t1 SET b = b || b WHERE f_leak(b);
NOTICE: f_leak => bbb
! NOTICE: f_leak => dad
NOTICE: f_leak => bcd
NOTICE: f_leak => def
NOTICE: f_leak => yyy
*************** EXPLAIN (COSTS OFF) UPDATE only t1 SET b
*** 1105,1131 ****
UPDATE only t1 SET b = b || '_updt' WHERE f_leak(b);
NOTICE: f_leak => bbbbbb
! NOTICE: f_leak => dddddd
-- returning clause with system column
UPDATE only t1 SET b = b WHERE f_leak(b) RETURNING oid, *, t1;
NOTICE: f_leak => bbbbbb_updt
! NOTICE: f_leak => dddddd_updt
oid | a | b | t1
-----+---+-------------+-----------------
102 | 2 | bbbbbb_updt | (2,bbbbbb_updt)
! 104 | 4 | dddddd_updt | (4,dddddd_updt)
(2 rows)
UPDATE t1 SET b = b WHERE f_leak(b) RETURNING *;
NOTICE: f_leak => bbbbbb_updt
! NOTICE: f_leak => dddddd_updt
NOTICE: f_leak => bcdbcd
NOTICE: f_leak => defdef
NOTICE: f_leak => yyyyyy
a | b
---+-------------
2 | bbbbbb_updt
! 4 | dddddd_updt
2 | bcdbcd
4 | defdef
2 | yyyyyy
--- 1105,1131 ----
UPDATE only t1 SET b = b || '_updt' WHERE f_leak(b);
NOTICE: f_leak => bbbbbb
! NOTICE: f_leak => daddad
-- returning clause with system column
UPDATE only t1 SET b = b WHERE f_leak(b) RETURNING oid, *, t1;
NOTICE: f_leak => bbbbbb_updt
! NOTICE: f_leak => daddad_updt
oid | a | b | t1
-----+---+-------------+-----------------
102 | 2 | bbbbbb_updt | (2,bbbbbb_updt)
! 104 | 4 | daddad_updt | (4,daddad_updt)
(2 rows)
UPDATE t1 SET b = b WHERE f_leak(b) RETURNING *;
NOTICE: f_leak => bbbbbb_updt
! NOTICE: f_leak => daddad_updt
NOTICE: f_leak => bcdbcd
NOTICE: f_leak => defdef
NOTICE: f_leak => yyyyyy
a | b
---+-------------
2 | bbbbbb_updt
! 4 | daddad_updt
2 | bcdbcd
4 | defdef
2 | yyyyyy
*************** NOTICE: f_leak => yyyyyy
*** 1133,1146 ****
UPDATE t1 SET b = b WHERE f_leak(b) RETURNING oid, *, t1;
NOTICE: f_leak => bbbbbb_updt
! NOTICE: f_leak => dddddd_updt
NOTICE: f_leak => bcdbcd
NOTICE: f_leak => defdef
NOTICE: f_leak => yyyyyy
oid | a | b | t1
-----+---+-------------+-----------------
102 | 2 | bbbbbb_updt | (2,bbbbbb_updt)
! 104 | 4 | dddddd_updt | (4,dddddd_updt)
202 | 2 | bcdbcd | (2,bcdbcd)
204 | 4 | defdef | (4,defdef)
302 | 2 | yyyyyy | (2,yyyyyy)
--- 1133,1146 ----
UPDATE t1 SET b = b WHERE f_leak(b) RETURNING oid, *, t1;
NOTICE: f_leak => bbbbbb_updt
! NOTICE: f_leak => daddad_updt
NOTICE: f_leak => bcdbcd
NOTICE: f_leak => defdef
NOTICE: f_leak => yyyyyy
oid | a | b | t1
-----+---+-------------+-----------------
102 | 2 | bbbbbb_updt | (2,bbbbbb_updt)
! 104 | 4 | daddad_updt | (4,daddad_updt)
202 | 2 | bcdbcd | (2,bcdbcd)
204 | 4 | defdef | (4,defdef)
302 | 2 | yyyyyy | (2,yyyyyy)
*************** AND f_leak(t1_1.b) AND f_leak(t1_2.b) RE
*** 1328,1342 ****
UPDATE t1 t1_1 SET b = t1_2.b FROM t1 t1_2
WHERE t1_1.a = 4 AND t1_2.a = t1_1.a AND t1_2.b = t1_1.b
AND f_leak(t1_1.b) AND f_leak(t1_2.b) RETURNING *, t1_1, t1_2;
! NOTICE: f_leak => dddddd_updt
! NOTICE: f_leak => dddddd_updt
NOTICE: f_leak => defdef
NOTICE: f_leak => defdef
! NOTICE: f_leak => dddddd_updt
NOTICE: f_leak => defdef
a | b | a | b | t1_1 | t1_2
---+-------------+---+-------------+-----------------+-----------------
! 4 | dddddd_updt | 4 | dddddd_updt | (4,dddddd_updt) | (4,dddddd_updt)
4 | defdef | 4 | defdef | (4,defdef) | (4,defdef)
(2 rows)
--- 1328,1342 ----
UPDATE t1 t1_1 SET b = t1_2.b FROM t1 t1_2
WHERE t1_1.a = 4 AND t1_2.a = t1_1.a AND t1_2.b = t1_1.b
AND f_leak(t1_1.b) AND f_leak(t1_2.b) RETURNING *, t1_1, t1_2;
! NOTICE: f_leak => daddad_updt
! NOTICE: f_leak => daddad_updt
NOTICE: f_leak => defdef
NOTICE: f_leak => defdef
! NOTICE: f_leak => daddad_updt
NOTICE: f_leak => defdef
a | b | a | b | t1_1 | t1_2
---+-------------+---+-------------+-----------------+-----------------
! 4 | daddad_updt | 4 | daddad_updt | (4,daddad_updt) | (4,daddad_updt)
4 | defdef | 4 | defdef | (4,defdef) | (4,defdef)
(2 rows)
*************** SELECT * FROM t1 ORDER BY a,b;
*** 1354,1360 ****
3 | ccc
3 | cde
3 | zzz
! 4 | dddddd_updt
4 | defdef
(11 rows)
--- 1354,1360 ----
3 | ccc
3 | cde
3 | zzz
! 4 | daddad_updt
4 | defdef
(11 rows)
*************** EXPLAIN (COSTS OFF) DELETE FROM t1 WHERE
*** 1397,1407 ****
DELETE FROM only t1 WHERE f_leak(b) RETURNING oid, *, t1;
NOTICE: f_leak => bbbbbb_updt
! NOTICE: f_leak => dddddd_updt
oid | a | b | t1
-----+---+-------------+-----------------
102 | 2 | bbbbbb_updt | (2,bbbbbb_updt)
! 104 | 4 | dddddd_updt | (4,dddddd_updt)
(2 rows)
DELETE FROM t1 WHERE f_leak(b) RETURNING oid, *, t1;
--- 1397,1407 ----
DELETE FROM only t1 WHERE f_leak(b) RETURNING oid, *, t1;
NOTICE: f_leak => bbbbbb_updt
! NOTICE: f_leak => daddad_updt
oid | a | b | t1
-----+---+-------------+-----------------
102 | 2 | bbbbbb_updt | (2,bbbbbb_updt)
! 104 | 4 | daddad_updt | (4,daddad_updt)
(2 rows)
DELETE FROM t1 WHERE f_leak(b) RETURNING oid, *, t1;
*************** INSERT INTO z1 VALUES
*** 1656,1673 ****
(1, 'aba'),
(2, 'bbb'),
(3, 'ccc'),
! (4, 'ddd');
CREATE POLICY p1 ON z1 TO regress_rls_group1 USING (a % 2 = 0);
CREATE POLICY p2 ON z1 TO regress_rls_group2 USING (a % 2 = 1);
ALTER TABLE z1 ENABLE ROW LEVEL SECURITY;
SET SESSION AUTHORIZATION regress_rls_bob;
SELECT * FROM z1 WHERE f_leak(b);
NOTICE: f_leak => bbb
! NOTICE: f_leak => ddd
a | b
---+-----
2 | bbb
! 4 | ddd
(2 rows)
EXPLAIN (COSTS OFF) SELECT * FROM z1 WHERE f_leak(b);
--- 1656,1673 ----
(1, 'aba'),
(2, 'bbb'),
(3, 'ccc'),
! (4, 'dad');
CREATE POLICY p1 ON z1 TO regress_rls_group1 USING (a % 2 = 0);
CREATE POLICY p2 ON z1 TO regress_rls_group2 USING (a % 2 = 1);
ALTER TABLE z1 ENABLE ROW LEVEL SECURITY;
SET SESSION AUTHORIZATION regress_rls_bob;
SELECT * FROM z1 WHERE f_leak(b);
NOTICE: f_leak => bbb
! NOTICE: f_leak => dad
a | b
---+-----
2 | bbb
! 4 | dad
(2 rows)
EXPLAIN (COSTS OFF) SELECT * FROM z1 WHERE f_leak(b);
*************** EXPLAIN (COSTS OFF) EXECUTE plancache_te
*** 1722,1732 ****
SET ROLE regress_rls_group1;
SELECT * FROM z1 WHERE f_leak(b);
NOTICE: f_leak => bbb
! NOTICE: f_leak => ddd
a | b
---+-----
2 | bbb
! 4 | ddd
(2 rows)
EXPLAIN (COSTS OFF) SELECT * FROM z1 WHERE f_leak(b);
--- 1722,1732 ----
SET ROLE regress_rls_group1;
SELECT * FROM z1 WHERE f_leak(b);
NOTICE: f_leak => bbb
! NOTICE: f_leak => dad
a | b
---+-----
2 | bbb
! 4 | dad
(2 rows)
EXPLAIN (COSTS OFF) SELECT * FROM z1 WHERE f_leak(b);
*************** SELECT * FROM rls_view;
*** 1900,1912 ****
NOTICE: f_leak => aba
NOTICE: f_leak => bbb
NOTICE: f_leak => ccc
! NOTICE: f_leak => ddd
a | b
---+-----
1 | aba
2 | bbb
3 | ccc
! 4 | ddd
(4 rows)
EXPLAIN (COSTS OFF) SELECT * FROM rls_view;
--- 1900,1912 ----
NOTICE: f_leak => aba
NOTICE: f_leak => bbb
NOTICE: f_leak => ccc
! NOTICE: f_leak => dad
a | b
---+-----
1 | aba
2 | bbb
3 | ccc
! 4 | dad
(4 rows)
EXPLAIN (COSTS OFF) SELECT * FROM rls_view;
*************** SELECT * FROM rls_view;
*** 1922,1934 ****
NOTICE: f_leak => aba
NOTICE: f_leak => bbb
NOTICE: f_leak => ccc
! NOTICE: f_leak => ddd
a | b
---+-----
1 | aba
2 | bbb
3 | ccc
! 4 | ddd
(4 rows)
EXPLAIN (COSTS OFF) SELECT * FROM rls_view;
--- 1922,1934 ----
NOTICE: f_leak => aba
NOTICE: f_leak => bbb
NOTICE: f_leak => ccc
! NOTICE: f_leak => dad
a | b
---+-----
1 | aba
2 | bbb
3 | ccc
! 4 | dad
(4 rows)
EXPLAIN (COSTS OFF) SELECT * FROM rls_view;
*************** GRANT SELECT ON rls_view TO regress_rls_
*** 1948,1958 ****
SET SESSION AUTHORIZATION regress_rls_alice;
SELECT * FROM rls_view;
NOTICE: f_leak => bbb
! NOTICE: f_leak => ddd
a | b
---+-----
2 | bbb
! 4 | ddd
(2 rows)
EXPLAIN (COSTS OFF) SELECT * FROM rls_view;
--- 1948,1958 ----
SET SESSION AUTHORIZATION regress_rls_alice;
SELECT * FROM rls_view;
NOTICE: f_leak => bbb
! NOTICE: f_leak => dad
a | b
---+-----
2 | bbb
! 4 | dad
(2 rows)
EXPLAIN (COSTS OFF) SELECT * FROM rls_view;
*************** EXPLAIN (COSTS OFF) SELECT * FROM rls_vi
*** 1969,1979 ****
SET SESSION AUTHORIZATION regress_rls_bob;
SELECT * FROM rls_view;
NOTICE: f_leak => bbb
! NOTICE: f_leak => ddd
a | b
---+-----
2 | bbb
! 4 | ddd
(2 rows)
EXPLAIN (COSTS OFF) SELECT * FROM rls_view;
--- 1969,1979 ----
SET SESSION AUTHORIZATION regress_rls_bob;
SELECT * FROM rls_view;
NOTICE: f_leak => bbb
! NOTICE: f_leak => dad
a | b
---+-----
2 | bbb
! 4 | dad
(2 rows)
EXPLAIN (COSTS OFF) SELECT * FROM rls_view;
*************** SET SESSION AUTHORIZATION regress_rls_bo
*** 1996,2006 ****
GRANT SELECT ON rls_view TO regress_rls_carol;
SELECT * FROM rls_view;
NOTICE: f_leak => bbb
! NOTICE: f_leak => ddd
a | b
---+-----
2 | bbb
! 4 | ddd
(2 rows)
EXPLAIN (COSTS OFF) SELECT * FROM rls_view;
--- 1996,2006 ----
GRANT SELECT ON rls_view TO regress_rls_carol;
SELECT * FROM rls_view;
NOTICE: f_leak => bbb
! NOTICE: f_leak => dad
a | b
---+-----
2 | bbb
! 4 | dad
(2 rows)
EXPLAIN (COSTS OFF) SELECT * FROM rls_view;
diff --git a/src/test/regress/sql/rowsecurity.sql b/src/test/regress/sql/rowsecurity.sql
new file mode 100644
index 785ac84..7fcefe4
*** a/src/test/regress/sql/rowsecurity.sql
--- b/src/test/regress/sql/rowsecurity.sql
*************** COPY t1 FROM stdin WITH (oids);
*** 203,209 ****
101 1 aba
102 2 bbb
103 3 ccc
! 104 4 ddd
\.
CREATE TABLE t2 (c float) INHERITS (t1);
--- 203,209 ----
101 1 aba
102 2 bbb
103 3 ccc
! 104 4 dad
\.
CREATE TABLE t2 (c float) INHERITS (t1);
*************** INSERT INTO z1 VALUES
*** 638,644 ****
(1, 'aba'),
(2, 'bbb'),
(3, 'ccc'),
! (4, 'ddd');
CREATE POLICY p1 ON z1 TO regress_rls_group1 USING (a % 2 = 0);
CREATE POLICY p2 ON z1 TO regress_rls_group2 USING (a % 2 = 1);
--- 638,644 ----
(1, 'aba'),
(2, 'bbb'),
(3, 'ccc'),
! (4, 'dad');
CREATE POLICY p1 ON z1 TO regress_rls_group1 USING (a % 2 = 0);
CREATE POLICY p2 ON z1 TO regress_rls_group2 USING (a % 2 = 1);
Jeff Janes <jeff.janes@gmail.com> writes:
The attached patch fixes regression tests for Welsh (cy_GB), needed in
9.5 and 9.6.
Pushed, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 07/22/2016 03:59 AM, Jeff Janes wrote:
On Thu, Jul 21, 2016 at 2:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I see that the core tests fall over in Turkish still :-(
Turkish has never passed (at least back to 9.0). It looks like it is
in the stemming functions. I don't understand why, I would think
everything other than English would be failing those if the regression
tests hard-code English stemming expectations but fail to arrange for
English stemming rules.
If something fails for Turkish but not other languages it is usually due
to the upper/lower casing rules of the dotted and the dotless I (I -> ı
and İ -> i rather than most languages which have I -> i).
Andreas
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jul 21, 2016 at 03:53:45PM -0400, Andrew Dunstan wrote:
On 07/21/2016 02:26 PM, Greg Stark wrote:
On Thu, Jul 21, 2016 at 5:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Confirmed here. Will deal with it, but I wonder why we have no buildfarm
members covering this ...We're not going to have a build farm member for every locale the local
systems support.Perhaps the build farm script should pick a random locale for each
run. Either a random locale from the set on the OS or a random
language from a list of locale that the regression tests are intended
to be safe for.I don't see why we shouldn't have a buildfarm machine that tests a very
large number of locales. It takes a very lightly resourced machine like
nightjar just over two minutes per locale. The list of locales to test is a
setting in the config file.
+1. Ten animals of ~75 locales apiece would give fair per-animal runtime.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 21/07 08.42, Jeff Janes wrote:
In Danish, the sequence 'aa' is sometimes treated as a single letter
which collates after 'z'.
For the record: this is also true for Norwegian, in both locales it
collates equal to 'Ã¥' which is the 29th letter of the alphabet. But
'aa' is no longer used in ordinary words, only names (in Norwegian
only personal names, in Danish also place names).
- Bjorn Munch
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers