Fix ordering of GRANT commands in pg_dumpall for tablespaces
This uses a method similar to 68a7c24f and now b8c6014 (applied for
database creation), which guarantees that GRANT commands using the WITH
GRANT OPTION are dumped in a way so as cascading dependencies are
respected. Note that tablespac
Fix ordering of GRANT commands in pg_dumpall for tablespaces
This uses a method similar to 68a7c24f and now b8c6014 (applied for
database creation), which guarantees that GRANT commands using the WITH
GRANT OPTION are dumped in a way so as cascading dependencies are
respected. Note that tablespac
Fix ordering of GRANT commands in pg_dumpall for tablespaces
This uses a method similar to 68a7c24f and now b8c6014 (applied for
database creation), which guarantees that GRANT commands using the WITH
GRANT OPTION are dumped in a way so as cascading dependencies are
respected. Note that tablespac
Fix ordering of GRANT commands in pg_dumpall for tablespaces
This uses a method similar to 68a7c24f and now b8c6014 (applied for
database creation), which guarantees that GRANT commands using the WITH
GRANT OPTION are dumped in a way so as cascading dependencies are
respected. Note that tablespac
Remove -o/--oids from pg_dumpall
This has been forgotten in 578b229, which has removed support for WITH
OIDS.
Discussion:
https://postgr.es/m/calay4q99fcfcog6ddke0v-aksge82l_+bhdwgefgzbakb84...@mail.gmail.com
Author: Surafel Temesgen
Branch
--
master
Details
---
https://git.postgresql.
Robert Haas writes:
> At the risk of being labeled a stickler for the details, this thread
> is both on the wrong mailing list and discussing a topic quite
> different from what the subject line would suggest.
Fair complaint. Redirected to -hackers at
https://postgr.es/m/[email protected]
On Wed, May 22, 2019 at 4:57 PM Tom Lane wrote:
>
> =?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= writes:
> > There are some case I missed to force us to use
pg_get_publication_tables
> > SRF instead of use pg_publication_rel ??
>
> pg_publication_rel isn't going to provide the correct expansion of
>
=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= writes:
> There are some case I missed to force us to use pg_get_publication_tables
> SRF instead of use pg_publication_rel ??
pg_publication_rel isn't going to provide the correct expansion of
a FOR ALL TABLES publication, IIUC.
r
On Wed, May 22, 2019 at 3:01 PM Tom Lane wrote:
>
> =?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= writes:
> > Just one doubt, why use LATERAL with pg_get_publication_tables SRF
instead
> > of JOIN direct to pg_publication_rel?
>
> Yes, LATERAL is just a noise word in this context, but I think
> it's g
=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= writes:
> Just one doubt, why use LATERAL with pg_get_publication_tables SRF instead
> of JOIN direct to pg_publication_rel?
Yes, LATERAL is just a noise word in this context, but I think
it's good for documentation purposes.
If you're asking why I used a
On Wed, May 22, 2019 at 12:47 PM Tom Lane wrote:
>
> Fix O(N^2) performance issue in pg_publication_tables view.
>
> The original coding of this view relied on a correlated IN sub-query.
> Our planner is not very bright about correlated sub-queries, and even
> if it were, there's no way for it to
Initial pgperltidy run for v12.
Make all the perl code look nice, too (for some value of "nice").
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/db6e2b4c52ade524f3db419d75084728e96e1f9c
Modified Files
--
src/backend/catalog/genbki.pl|
Phase 2 pgindent run for v12.
Switch to 2.1 version of pg_bsd_indent. This formats
multiline function declarations "correctly", that is with
additional lines of parameter declarations indented to match
where the first line's left parenthesis is.
Discussion:
https://postgr.es/m/CAEepm=0p3fetxrcu
Initial pgindent run for v12.
This is still using the 2.0 version of pg_bsd_indent.
I thought it would be good to commit this separately,
so as to document the differences between 2.0 and 2.1 behavior.
Discussion: https://postgr.es/m/[email protected]
Branch
--
master
Details
-
Convert ExecComputeStoredGenerated to use tuple slots
This code was still using the old style of forming a heap tuple rather
than using tuple slots. This would be less efficient if a non-heap
access method was used. And using tuple slots is actually quite a bit
faster when using heap as well.
A
Mention ANALYZE boolean options in documentation.
Commit 41b54ba78e allowed not only VACUUM but also ANALYZE options
to take a boolean argument. But it forgot to update the documentation
for ANALYZE. This commit adds the descriptions about those ANALYZE
boolean options into the documentation.
Thi
Fix O(N^2) performance issue in pg_publication_tables view.
The original coding of this view relied on a correlated IN sub-query.
Our planner is not very bright about correlated sub-queries, and even
if it were, there's no way for it to know that the output of
pg_get_publication_tables() is duplic
docs: PG 12 release notes, support functions
Move support function mention to the proper section, and reword.
Reported-by: Tom Lane
Discussion: https://postgr.es/m/[email protected]
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/728840fe13acff7b03a4b
doc: PG 12 relnotes, correct recovery_target* variable mention
Clarify new restriction on recovery_target* variables.
Reported-by: Gaby Schilders
Discussion: reported via chat
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/ba95a6933632410d103d6f17cd3bc1adf92a08
Add .gitignore entries for new ecpg test case.
Oversight in commit a1dc6ab465986a62b308dd1bb8da316b5ed9685a.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/4a657ab260499381c645673ca1c3255adc0b2ace
Modified Files
--
src/interfaces/ecpg/test/sql/.gitigno
In transam.h, don't expose static inline functions to frontend code.
That leads to unsatisfied external references if the C compiler fails
to elide unused static functions. Apparently, we have no buildfarm
members building HEAD that have that issue ... but such compilers still
exist in the wild.
On Tue, May 21, 2019 at 4:50 PM Andres Freund wrote:
> Indeed.
At the risk of being labeled a stickler for the details, this thread
is both on the wrong mailing list and discussing a topic quite
different from what the subject line would suggest.
--
Robert Haas
EnterpriseDB: http://www.enterpri
> This is a new feature and not a bug fix, hence why has this been
> committed to HEAD knowing that the feature freeze of v12 is effective
> as of the 8th of April? You should have waited until REL_12_STABLE
> has been created for new features.
Please see the thread on hackers. Yes, it is a new f
23 matches
Mail list logo
