Re: pgsql: Remove special outfuncs/readfuncs handling of RangeVar.catalogna

tion to include utility commands (787102b56). > Remove the special case and just treat this field normally. > > Bump catversion out of an abundance of caution --- I do not think > we currently ever store RangeVar nodes in the catalogs, but > perhaps I'm wrong. > > Per report fr

Re: pgsql: Default to hidden visibility for extension libraries where possi

Hi po 18. 7. 2022 v 3:06 odesílatel Andres Freund napsal: > Default to hidden visibility for extension libraries where possible > > Until now postgres built extension libraries with global visibility, i.e. > exporting all symbols. On the one platform where that behavior is not > natively

Re: pgsql: pg_alterckey: remove TAP check rules from Makefile

so 26. 12. 2020 v 16:33 odesílatel Bruce Momjian napsal: > aOn Sat, Dec 26, 2020 at 10:27:24AM -0500, Bruce Momjian wrote: > > Thank you for your report. When I did the Windows port and pg_upgrade, > > we didn't have all of the test infrastructure we have now, so I wasn't > > even aware of all

Re: pgsql: pg_alterckey: remove TAP check rules from Makefile

so 26. 12. 2020 v 16:27 odesílatel Bruce Momjian napsal: > On Sat, Dec 26, 2020 at 04:23:59PM +0100, Pavel Stehule wrote: > > Details > > --- > > https://git.postgresql.org/pg/commitdiff/ > > e174a6f1937248886e124cdb68408e727aeea278

Re: pgsql: pg_alterckey: remove TAP check rules from Makefile

so 26. 12. 2020 v 15:03 odesílatel Bruce Momjian napsal: > pg_alterckey: remove TAP check rules from Makefile > > Reported-by: Pavel Stehule, Michael Paquier > > Discussion: > https://postgr.es/m/cafj8prbrno4co5bqcx4blx1zz45z_t-oppxa+u7slp7gatb...@mail.gmail.com > > B

Re: pgsql: Add pg_alterckey utility to change the cluster key

so 26. 12. 2020 v 7:25 odesílatel Pavel Stehule napsal: > > > so 26. 12. 2020 v 7:20 odesílatel Bruce Momjian napsal: > >> On Sat, Dec 26, 2020 at 06:18:01AM +0100, Pavel Stehule wrote: >> > Details >> > --- >> >

Re: pgsql: Add pg_alterckey utility to change the cluster key

so 26. 12. 2020 v 7:20 odesílatel Bruce Momjian napsal: > On Sat, Dec 26, 2020 at 06:18:01AM +0100, Pavel Stehule wrote: > > Details > > --- > > https://git.postgresql.org/pg/commitdiff/ > > 62afb42a7f9f533efc6c19f462c3a848fa4ddb63

Re: pgsql: Refactor pg_get_line() to expose an alternative StringInfo-based

po 7. 9. 2020 v 18:58 odesílatel Alvaro Herrera napsal: > On 2020-Sep-07, Tom Lane wrote: > > > Pavel Stehule writes: > > > here is a patch > > > > What exactly is this supposed to fix? > > > > I didn't bother tracking down exactly where initdb.c is

Re: pgsql: Refactor pg_get_line() to expose an alternative StringInfo-based

po 7. 9. 2020 v 16:48 odesílatel Tom Lane napsal: > Alvaro Herrera writes: > > On 2020-Sep-07, Pavel Stehule wrote: > >> I tried to reuse this new API in pg_dump.c, and I had a problem with > >> private struct StringInfo. > > >> maybe there should be

Re: pgsql: Refactor pg_get_line() to expose an alternative StringInfo-based

Hi ne 6. 9. 2020 v 20:13 odesílatel Tom Lane napsal: > Refactor pg_get_line() to expose an alternative StringInfo-based API. > > Letting the caller provide a StringInfo to read into is helpful when > the caller needs to merge lines or otherwise modify the data after > it's been read. Notably,

Re: pgsql: Fix plpgsql to re-look-up composite type names at need.

pá 16. 8. 2019 v 17:06 odesílatel Tom Lane napsal: > Pavel Stehule writes: > > čt 15. 8. 2019 v 21:22 odesílatel Tom Lane napsal: > >> I'm slightly hesitant to back-patch this into v11, because it changes > >> the contents of struct PLpgSQL_ty

Re: pgsql: Fix plpgsql to re-look-up composite type names at need.

Hi čt 15. 8. 2019 v 21:22 odesílatel Tom Lane napsal: > > > I'm slightly hesitant to back-patch this into v11, because it changes > the contents of struct PLpgSQL_type as well as the signature of > plpgsql_build_datatype(), so in principle it could break code that is > poking into the innards