test_ddl_deparse: Don't use pg_class as source for a matview
Doing so causes a pg_upgrade of a database containing these objects to
fail whenever pg_class changes. And it's pointless anyway: we have more
interesting tables anyhow.
Discussion:
https://postgr.es/m/CAD5tBc+s8pW9WvH2+_z=b4x95fd4quz
test_ddl_deparse: Don't use pg_class as source for a matview
Doing so causes a pg_upgrade of a database containing these objects to
fail whenever pg_class changes. And it's pointless anyway: we have more
interesting tables anyhow.
Discussion:
https://postgr.es/m/CAD5tBc+s8pW9WvH2+_z=b4x95fd4quz
test_ddl_deparse: Don't use pg_class as source for a matview
Doing so causes a pg_upgrade of a database containing these objects to
fail whenever pg_class changes. And it's pointless anyway: we have more
interesting tables anyhow.
Discussion:
https://postgr.es/m/CAD5tBc+s8pW9WvH2+_z=b4x95fd4quz
test_ddl_deparse: Don't use pg_class as source for a matview
Doing so causes a pg_upgrade of a database containing these objects to
fail whenever pg_class changes. And it's pointless anyway: we have more
interesting tables anyhow.
Discussion:
https://postgr.es/m/CAD5tBc+s8pW9WvH2+_z=b4x95fd4quz
Andrew Dunstan wrote:
> As I mentioned upthread, it's not supposed to be, but was being due to
> a typo that I have fixed. You should see this error cleared on the
> dashboard in a few minutes.
>
> However, in general the module tries to do a maximal test. That
> includes almost all the contrib d
restrict -> pg_restrict
So that it works on MSVC, too.
Author: Michaël Paquier
Discussion: https://postgr.es/m/29889.1520968...@sss.pgh.pa.us
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/8d1b805fcc57be47d3269a13eb01d993fe768295
Modified Files
--
src
Michael Paquier wrote:
> Attached is a patch which fixes the compilation failure on Windows for
> me. That should put the buildfarm back to green.
Pushed, thanks -- let's see how that goes.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remo
Alvaro Herrera writes:
> Well, maybe we should dictate policy that it must be possible to
> pg_upgrade this database too; then we'll just have to work so that it
> always works. I have fixed the current problem and I'm open to the idea
> of keeping it working.
Name of the matview now seems a bit
Pass additional arguments to a couple of grouping-related functions.
get_number_of_groups() and make_partial_grouping_target() currently
fish information directly out of the PlannerInfo; in the former case,
the target list, and in the latter case, the HAVING qual. This works
fine if there's only
Fix more format truncation issues
Fix the warnings created by the compiler warning options
-Wformat-overflow=2 -Wformat-truncation=2, supported since GCC 7. This
is a more aggressive variant of the fixes in
6275f5d28a1577563f53f2171689d4f890a46881, which GCC 7 warned about by
default.
The issues
Alvaro Herrera writes:
> Michael Paquier wrote:
>> Attached is a patch which fixes the compilation failure on Windows for
>> me. That should put the buildfarm back to green.
> Pushed, thanks -- let's see how that goes.
build now works, ecpg tests fail.
regards, tom lane
Clean up duplicate role and schema names in regression tests.
Since these names are global, using the same ones in different regression
tests creates a hazard of test failures if any two such scripts run
concurrently. Let's establish a policy of not doing that. In the cases
where a conflict exis
Clean up duplicate role and schema names in regression tests.
Since these names are global, using the same ones in different regression
tests creates a hazard of test failures if any two such scripts run
concurrently. Let's establish a policy of not doing that. In the cases
where a conflict exis
test_ddl_deparse: rename matview
Should have done this in e69f5e0efca ...
Per note from Tom Lane.
Branch
--
REL9_5_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/492ba06942347dc20721db77fe00460013d9dc70
Modified Files
--
src/test/modules/test_ddl_deparse/expecte
test_ddl_deparse: rename matview
Should have done this in e69f5e0efca ...
Per note from Tom Lane.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/a446a1c70f65c6c68598c2160b530606fa1b5c38
Modified Files
--
src/test/modules/test_ddl_deparse/expected/matvi
test_ddl_deparse: rename matview
Should have done this in e69f5e0efca ...
Per note from Tom Lane.
Branch
--
REL9_6_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/eb1c481ac3975574c1709042efe2c6c32a937a23
Modified Files
--
src/test/modules/test_ddl_deparse/expecte
test_ddl_deparse: rename matview
Should have done this in e69f5e0efca ...
Per note from Tom Lane.
Branch
--
REL_10_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/12bcecae10f7986407fedeb3dd795556027a9d96
Modified Files
--
src/test/modules/test_ddl_deparse/expecte
Split create_grouping_paths into degenerate and non-degenerate cases.
There's no functional change here, or at least I hope there isn't,
just code rearrangement. The rearrangement is motivated by
partition-wise aggregate, which doesn't need to consider the
degenerate case but wants to reuse the l
Tom Lane wrote:
> Alvaro Herrera writes:
> > Michael Paquier wrote:
> >> Attached is a patch which fixes the compilation failure on Windows for
> >> me. That should put the buildfarm back to green.
>
> > Pushed, thanks -- let's see how that goes.
>
> build now works, ecpg tests fail.
I stared
ah, but bowerbird is OK on ecpg, this is only failing on thrips, whelk,
woodlouse. It sounds related to 32 vs. 64 bits ...
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch
Alvaro Herrera writes:
> Tom Lane wrote:
>> build now works, ecpg tests fail.
> I stared at the code for a while, didn't notice anything amiss. I'm
> mystified. Peter?
I'm wondering if the Windows environment is somehow supplying a
"strtoint" that isn't actually ABI-compatible with ours.
A di
Oh ... duh. We've been assuming that the strtoint change broke it,
but that's wrong. The test case that is failing is new as of yesterday,
and the correct answer is that it's never worked on Windows. See
https://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=3b7ab4380440d7b14ee390fa
Peter Eisentraut writes:
> Add tests for reinit.c
BTW, buildfarm member jacana hasn't succeeded at this test once.
The failures look like
ok 1 - init fork in base exists
ok 2 - main fork in base exists
error running SQL: 'psql::1: ERROR: directory
"/home/pgrunner/bf/root/HEAD/pgsql.build/src/t
On Thu, Mar 15, 2018 at 06:57:27PM -0400, Tom Lane wrote:
> I think what's wrong is that src/tools/msvc/ecpg_regression.proj
> needs to be taught that tests under ecpg/test/compat-oracle need
> to be run with "-C ORACLE". Neither that directory nor that
> switch existed before yesterday. There's
Fix msvc/ecpg_regression.proj for recent ECPG test additions.
Commit 3b7ab4380 added some tests that require ecpg to be given the
new "-C ORACLE" switch. Teach the MSVC build infrastructure about
that.
Michael Paquier
Discussion: https://postgr.es/m/8299.1521154...@sss.pgh.pa.us
Branch
--
Michael Paquier writes:
> On Thu, Mar 15, 2018 at 06:57:27PM -0400, Tom Lane wrote:
>> I think what's wrong is that src/tools/msvc/ecpg_regression.proj
>> needs to be taught that tests under ecpg/test/compat-oracle need
>> to be run with "-C ORACLE". Neither that directory nor that
>> switch exis
Alvaro Herrera writes:
> ah, but bowerbird is OK on ecpg, this is only failing on thrips, whelk,
> woodlouse. It sounds related to 32 vs. 64 bits ...
BTW, the reason why bowerbird was green had nothing to do with 32
or 64 bits, but rather that it isn't running the ecpg tests:
'i
On Thu, Mar 15, 2018 at 10:37:06PM -0400, Tom Lane wrote:
> Seems sane AFAICT, so pushed. Thanks!
Thanks, Tom.
--
Michael
signature.asc
Description: PGP signature
I wrote:
> Peter Eisentraut writes:
>> Add tests for reinit.c
> BTW, buildfarm member jacana hasn't succeeded at this test once.
> The failures look like
> ok 1 - init fork in base exists
> ok 2 - main fork in base exists
> error running SQL: 'psql::1: ERROR: directory
> "/home/pgrunner/bf/roo
On Fri, Mar 16, 2018 at 1:12 PM, Tom Lane wrote:
> Alvaro Herrera writes:
> > ah, but bowerbird is OK on ecpg, this is only failing on thrips, whelk,
> > woodlouse. It sounds related to 32 vs. 64 bits ...
>
> BTW, the reason why bowerbird was green had nothing to do with 32
> or 64 bits, but ra
32 matches
Mail list logo
