Re: partitioned tables and contrib/sepgsql
От | Mike Palmiotto |
---|---|
Тема | Re: partitioned tables and contrib/sepgsql |
Дата | |
Msg-id | CAMN686EjceBQu5UCb=Mz8fNQQN5YSPAE5kMAY8yaher-vaV9Gg@mail.gmail.com обсуждение исходный текст |
Ответ на | [HACKERS] partitioned tables and contrib/sepgsql (Stephen Frost <sfrost@snowman.net>) |
Список | pgsql-hackers |
On Wed, Apr 5, 2017 at 1:22 PM, Mike Palmiotto <mike.palmiotto@crunchydata.com> wrote: > On Wed, Apr 5, 2017 at 1:19 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: >>> On 4/5/17 12:04, Tom Lane wrote: >>>> Conclusion: Fedora's gcc is playing fast and loose somehow with the >>>> command "#include <stdbool.h>"; that does not include the file >>>> you'd think it does, it does something magic inside the compiler. >>>> The magic evidently includes not complaining about duplicate macro >>>> definitions for true and false. >> >>> Perhaps -Wsystem-headers would change the outcome in your case. >> >> Hah, you're right: with that, >> >> In file included from /usr/include/selinux/label.h:9:0, >> from label.c:40: >> /usr/lib/gcc/x86_64-redhat-linux/6.3.1/include/stdbool.h:34:0: warning: "true" redefined >> #define true 1 >> >> In file included from ../../src/include/postgres.h:47:0, >> from label.c:11: >> ../../src/include/c.h:206:0: note: this is the location of the previous definition >> #define true ((bool) 1) >> >> and likewise for "false". So that mystery is explained. >> >> I stand by my previous patch suggestion, except that we can replace >> the parenthetical comment with something like "(We don't care if >> <stdbool.h> redefines "true"/"false"; those are close enough.)". >> > > Sounds good. Updated patchset will include that verbiage, along with > some regression tests for partitioned tables. Looks like the label regression test is failing even without these changes. Weirdly enough, this only happens in one place: 84 SELECT objtype, objname, label FROM pg_seclabels 85 WHERE provider = 'selinux' AND objtype = 'column' AND (objname like 't3.%' OR objname like 't4.%'); I haven't figured out why this may be (yet), but it seems like we shouldn't assume the order of output from a SELECT. As I understand it, the order of the output is subject to change with changes to the planner/configuration. I'm going to hold the partition table regression changes for a separate patch and include some ORDER BY fixes. Will post tomorrow In the meantime, attached are the latest and greatest patches. Thanks, -- Mike Palmiotto Software Engineer Crunchy Data Solutions https://crunchydata.com
Вложения
В списке pgsql-hackers по дате отправления: