Re: Missing test of SPI copy functionality

On Thu, Nov 07, 2019 at 06:25:54AM -0800, Mark Dilger wrote: > Thanks for reviewing! After a closer lookup, I have noticed that you missed a second code path which is able to trigger the COPY failures as you use EXECUTE with COPY in PL/pgSQL. So I have added some tests for that, and committed

Re: Frequent HLL bitstream_unpack crashes

On Fri, Nov 8, 2019 at 8:30 PM Kirk, Steve wrote: > > I posted this as a comment in the HLL GitHub, but have yet to get a response > there: > > https://github.com/citusdata/postgresql-hll/issues/84 > I don't think this is the right mailing list to expect an answer to this problem. This

Re: 'Invalid lp' during heap_xlog_delete

I repro'ed on PG11 and PG10 STABLE but several months old. I looked at 6d05086 but it doesn't address the core issue. DropRelFileNodeBuffers prevents the checkpoint from writing all needed dirty pages for any REDO's that exist BEFORE the truncate. If we crash after a checkpoint but before the

Re: pg_upgrade fails with non-standard ACL

On Fri, Nov 08, 2019 at 06:03:06PM +0900, Michael Paquier wrote: > I have begun looking at this one. Another question I have: do we need to care more about other extra ACLs applied to other object types? For example a subset of columns on a table with a column being renamed could be an issue.

Re: logical replication empty transactions

Em seg., 21 de out. de 2019 às 21:20, Jeff Janes escreveu: > > After setting up logical replication of a slowly changing table using the > built in pub/sub facility, I noticed way more network traffic than made > sense. Looking into I see that every transaction in that database on the >

Re: Monitoring disk space from within the server

On Fri, Nov 08, 2019 at 03:10:57PM +0100, Julien Rouhaud wrote: > Agreed, inodes are probably not very useful there. Total bytes and free bytes looks like a good first cut. Have you looked at the portability of statfs() on other BSD flavors and Solaris? I recall from a lookup at statvfs() that

Re: [PATCH][DOC] Fix for PREPARE TRANSACTION doc and postgres_fdw message.

On Fri, Nov 08, 2019 at 10:19:01AM +0100, Gilles Darold wrote: > I don't think so. The support or not of 2PC is on foreign data wrapper > side. In postgres_fdw contrib the error for use with 2PC is not part of > the test but it will be thrown anyway. I guess that a test will be > valuable only if

First-draft back-branch release notes are up for review

See https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=1add2e09b9a4c2d2c72ce51991fa4efaf577a29f Please send any corrections by Sunday. regards, tom lane

Re: heapam_index_build_range_scan's anyvisible

On Fri, Nov 08, 2019 at 12:10:35PM -0800, Andres Freund wrote: > And pushed. Sorry that this took so long. Thanks Andres. I have updated the status of the patch in the CF app accordingly: https://commitfest.postgresql.org/25/2235/. -- Michael signature.asc Description: PGP signature

Re: Patch avoid call strlen repeatedly in loop.

On 11/8/19 9:41 AM, Ranier VF wrote: --- \dll\postgresql-12.0\a\backend\libpq\auth.c Mon Sep 30 17:06:55 2019 +++ auth.c Fri Nov 08 14:27:17 2019 @@ -1815,6 +1815,7 @@ charident_user[IDENT_USERNAME_MAX + 1]; pgsocketsock_fd = PGINVALID_SOCKET; /* for

Re: TestLib::command_fails_like enhancement

On 11/8/19 9:22 AM, Andrew Dunstan wrote: ... This will need to be rewritten in light of the above, but see Thanks for the reference. Having read your motivating example, this new review reverses

Re: Collation versions on Windows (help wanted, apply within)

On Fri, Nov 8, 2019 at 12:44 AM Thomas Munro wrote: > > Do any Windows hackers want to help get it into shape? Some things to > do: test it, verify that the _WIN32_WINNT >= 0x0600 stuff makes sense > (why do we target such ancient Windows releases anyway?) You have to keep in mind that

Re: Monitoring disk space from within the server

On Fri, Nov 08, 2019 at 04:06:21PM +0100, Christoph Berg wrote: Re: Tomas Vondra 2019-11-08 <20191108145025.d7pfcip6plufxiah@development> While I agree monitoring disk space is important, I think pretty much every deployment already does that using some other monitoring tool (which also

'Invalid lp' during heap_xlog_delete

Page on disk has empty lp 1 * Insert into page lp 1 checkpoint START.Redo eventually starts here. ** Delete all rows on page. autovac truncate DropRelFileNodeBuffers - dirty page NOT written. lp 1 on disk still empty checkpoint completes crash smgrtruncate - Not reached heap_xlog_delete

Re: heapam_index_build_range_scan's anyvisible

On 2019-11-08 01:22:45 -0800, Andres Freund wrote: > On 2019-11-07 09:25:40 -0800, Andres Freund wrote: > > On 2019-11-07 17:02:36 +0900, Michael Paquier wrote: > > > On Wed, Sep 25, 2019 at 10:24:05PM -0700, Ashwin Agrawal wrote: > > > > Thanks for reporting, I did indeed missed out contrib.

Re: Logical replication wal sender timestamp bug

On Wed, Nov 6, 2019 at 2:15 AM Michael Paquier wrote: > On Tue, Nov 05, 2019 at 01:19:37PM +0900, Michael Paquier wrote: > > On Sat, Nov 02, 2019 at 09:54:54PM -0400, Jeff Janes wrote: > >> Filling out the timestamp after the message has already been sent is > taking > >> "as late as possible" a

Re: Remove HeapTuple and Buffer dependency for predicate locking functions

On Thu, Nov 7, 2019 at 8:44 PM Thomas Munro wrote: > On Thu, Aug 8, 2019 at 6:53 AM Ashwin Agrawal wrote: > >>> - I wonder if CheckForSerializableConflictOutNeeded() shouldn't have a > >>> portion of it's code as a static inline. In particular, it's a shame > >>> that we currently perform

Re: errbacktrace

On 2019-Oct-26, Peter Eisentraut wrote: > I hadn't realized that you had already attached a patch that implements > your idea. It looks good to me. Maybe a small comment near > check_backtrace_functions() why we're not using a regular list. Other > than that, please go ahead with this.

Patch avoid call strlen repeatedly in loop.

Hi, Please can anybody review and commit this patch. Thanks. Ranier Vilela --- \dll\postgresql-12.0\a\backend\libpq\auth.c Mon Sep 30 17:06:55 2019 +++ auth.c Fri Nov 08 14:27:17 2019 @@ -1815,6 +1815,7 @@ charident_user[IDENT_USERNAME_MAX + 1]; pgsocket

Re: TestLib::command_fails_like enhancement

On 11/8/19 11:25 AM, Mark Dilger wrote: > > > On 11/8/19 6:33 AM, Andrew Dunstan wrote: >> >> On 11/8/19 1:16 AM, Craig Ringer wrote: >>> On Fri, 8 Nov 2019 at 06:28, Mark Dilger >> > wrote: >>> >>> >>> >>> On 10/31/19 10:02 AM, Andrew Dunstan wrote: >>>

Re: [PATCH] Add some useful asserts into View Options macroses

В письме от пятница, 1 ноября 2019 г. 13:29:58 MSK пользователь Peter Eisentraut написал: > Committed. > > I simplified the parentheses by one level from your patch. Thank you! -- Software Developer: https://www.upwork.com/freelancers/~014a87e140ff02c0da Body-oriented Therapist:

Re: tableam vs. TOAST

On Wed, Nov 6, 2019 at 12:00 PM Andres Freund wrote: > I'd like an AM to have the *option* of implementing something better, or > at least go in the direction of making that possible. OK. Could you see what you think of the attached patches? 0001 does some refactoring of toast_fetch_datum() and

Re: TestLib::command_fails_like enhancement

On 11/8/19 6:33 AM, Andrew Dunstan wrote: On 11/8/19 1:16 AM, Craig Ringer wrote: On Fri, 8 Nov 2019 at 06:28, Mark Dilger mailto:hornschnor...@gmail.com>> wrote: On 10/31/19 10:02 AM, Andrew Dunstan wrote: > > This small patch authored by my colleague Craig Ringer

Re: Refactor parse analysis of EXECUTE command

Peter Eisentraut writes: > On 2019-11-08 09:03, Pavel Stehule wrote: >> Minimally on SQL level is not possible do prepare on execute. So execute >> should be evaluate as one step. > Well, that's kind of the question that is being discussed in this thread. Yeah. Having now taken a quick look

Re: Binary support for pgoutput plugin

> On Tue, Nov 05, 2019 at 07:16:10AM -0500, Dave Cramer wrote: > > See attached --- a/src/backend/replication/logical/worker.c +++ b/src/backend/replication/logical/worker.c @@ -1779,6 +1779,7 @@ ApplyWorkerMain(Datum main_arg) options.slotname = myslotname;

Re: Why overhead of SPI is so large?

pá 8. 11. 2019 v 14:31 odesílatel Konstantin Knizhnik < k.knizh...@postgrespro.ru> napsal: > > > On 07.11.2019 15:09, Pavel Stehule wrote: > > > > čt 7. 11. 2019 v 13:03 odesílatel Kyotaro Horiguchi < > horikyota@gmail.com> napsal: > >> Hello. >> >> At Tue, 5 Nov 2019 22:14:40 +0100, Pavel

Re: Refactor parse analysis of EXECUTE command

pá 8. 11. 2019 v 13:34 odesílatel Peter Eisentraut < peter.eisentr...@2ndquadrant.com> napsal: > On 2019-11-08 09:03, Pavel Stehule wrote: > > Parse analysis of EXECUTE does not access any tables, so if I > > understood > > this correctly, this concern doesn't apply here. > > > > > >

Re: Monitoring disk space from within the server

Re: To Tomas Vondra 2019-11-08 <20191108150621.gl8...@msg.df7cb.de> > I think this should be directly in core because it's useful to a wide > range of users. Also, I want to have it in \db+ in psql where users would actually be looking for it. Christoph

Re: [Proposal] Global temporary tables

My comments for global_private_temp-4.patch good side: 1 Lots of index type on GTT. I think we need support for all kinds of indexes. 2 serial column on GTT. 3 INHERITS GTT. 4 PARTITION GTT. I didn't choose to support them in the first release, but you did. Other side: 1 case: create global

Re: Monitoring disk space from within the server

Re: Tomas Vondra 2019-11-08 <20191108145025.d7pfcip6plufxiah@development> > While I agree monitoring disk space is important, I think pretty much > every deployment already does that using some other monitoring tool > (which also monitors million other things). There are plenty of deployments

Re: Monitoring disk space from within the server

On Fri, Nov 08, 2019 at 02:24:19PM +0100, Christoph Berg wrote: Monitoring the available disk space is the topmost thing on the priority for PostgreSQL operation, yet this metric is not available from the SQL level. While I agree monitoring disk space is important, I think pretty much every

Re: pg_upgrade and subscriptions

Em sáb., 2 de nov. de 2019 às 13:55, Oleksii Kliukin escreveu: > > I came across a surprising behavior when upgrading our PostgreSQL 10 DBs that > also serve as a destination for the logical replication of some reference > tables. > > pg_upgrade turns off all subscriptions on the cluster and

Re: TestLib::command_fails_like enhancement

On 11/8/19 1:16 AM, Craig Ringer wrote: > On Fri, 8 Nov 2019 at 06:28, Mark Dilger > wrote: > > > > On 10/31/19 10:02 AM, Andrew Dunstan wrote: > > > > This small patch authored by my colleague Craig Ringer enhances > > Testlib's

Re: Planning counters in pg_stat_statements (using pgss_store)

On Fri, Nov 8, 2019 at 5:35 AM imai.yoshik...@fujitsu.com wrote: > > On Tue, Sept 10, 2019 at 11:27 PM, Julien Rouhaud wrote: > > > [0002 patch] > > > In pgss_planner_hook: > > > > > > + /* calc differences of buffer counters. */ > > > + bufusage =

Re: add a MAC check for TRUNCATE

On 11/8/19 9:02 AM, Yuli Khodorkovskiy wrote: > On Thu, Nov 7, 2019 at 7:46 PM Michael Paquier wrote: >> >> On Mon, Sep 30, 2019 at 11:38:05AM -0300, Alvaro Herrera wrote: >> > On 2019-Sep-30, Joe Conway wrote: >> > >> > > I am not sure I will get to this today. I assume it is ok for me to move

Re: ssl passphrase callback

On Thu, 7 Nov 2019 at 10:24, Bruce Momjian wrote: > What is the value of a shared library over a shell command? We had this > discussion in relation to archive_command years ago, and decided on a > shell command as the best API. > I don't recall such a discussion, but I can give perspective:

Re: Monitoring disk space from within the server

On Fri, Nov 8, 2019 at 2:58 PM Christoph Berg wrote: > > Re: Julien Rouhaud 2019-11-08 > > > The related function on Windows is apparently GetDiskFreeSpaceA [1]. > > There's a link to GetDiskFreeSpaceExA() which seems much easier to use > because it accepts any directory on the drive in

Re: add a MAC check for TRUNCATE

On Thu, Nov 7, 2019 at 7:46 PM Michael Paquier wrote: > > On Mon, Sep 30, 2019 at 11:38:05AM -0300, Alvaro Herrera wrote: > > On 2019-Sep-30, Joe Conway wrote: > > > > > I am not sure I will get to this today. I assume it is ok for me to move > > > it forward e.g. next weekend, or is that not in

Re: Monitoring disk space from within the server

Re: Julien Rouhaud 2019-11-08 > > We could append the quotactl(Q_GETQUOTA) information as well, but I'm > > not sure this has a sensible actual-users-to-noise ratio. > > Well, having a quota is one of the few real reason to create a > tablespace so it's probably worth it, although I have to

Re: Monitoring disk space from within the server

Re: Julien Rouhaud 2019-11-08 > The related function on Windows is apparently GetDiskFreeSpaceA [1]. There's a link to GetDiskFreeSpaceExA() which seems much easier to use because it accepts any directory on the drive in question:

Re: Monitoring disk space from within the server

On Fri, Nov 8, 2019 at 2:40 PM Christoph Berg wrote: > > Re: Julien Rouhaud 2019-11-08 > > > I'm also wondering if getting the fs > > information is enough, as there might be quota. > > We could append the quotactl(Q_GETQUOTA) information as well, but I'm > not sure this has a sensible

Performance improvement for queries with IN clause

Hello all, I would like to direct your attention to the queries of following type, select from where IN () the plan for such a query uses index scan (or index-only), now in our experiments, if the provided list is sorted then query performance improves by ~10%. Which makes sense also as once

Re: Monitoring disk space from within the server

On Fri, Nov 8, 2019 at 2:35 PM Christoph Berg wrote: > > Re: Julien Rouhaud 2019-11-08 > > > Shouldn't we have something more generic, in hope that this eventually > > get implemented on Windows? I'm also wondering if getting the fs > > information is enough, as there might be quota. > > The

Re: Monitoring disk space from within the server

Re: Julien Rouhaud 2019-11-08 > I'm also wondering if getting the fs > information is enough, as there might be quota. We could append the quotactl(Q_GETQUOTA) information as well, but I'm not sure this has a sensible actual-users-to-noise ratio. Christoph

Re: CountDBSubscriptions check in dropdb

On Mon, Oct 21, 2019 at 11:43 AM Amit Kapila wrote: > > While reviewing Pavel's patch for a new option in Drop Database > command [1], I noticed that the check for CountDBSubscriptions in > dropdb() is done after we kill the autovac workers and allowed other > backends to exit via

Re: Monitoring disk space from within the server

Re: Julien Rouhaud 2019-11-08 > Shouldn't we have something more generic, in hope that this eventually > get implemented on Windows? I'm also wondering if getting the fs > information is enough, as there might be quota. The name is certainly not a good pick, it's not meant to be a raw statfs()

Re: Monitoring disk space from within the server

On Fri, Nov 8, 2019 at 2:24 PM Christoph Berg wrote: > > Monitoring the available disk space is the topmost thing on the > priority for PostgreSQL operation, yet this metric is not available > from the SQL level. > > The attached patch implements a function pg_tablespace_statfs(tblspc) > to

Re: Why overhead of SPI is so large?

On 07.11.2019 15:09, Pavel Stehule wrote: čt 7. 11. 2019 v 13:03 odesílatel Kyotaro Horiguchi mailto:horikyota@gmail.com>> napsal: Hello. At Tue, 5 Nov 2019 22:14:40 +0100, Pavel Stehule mailto:pavel.steh...@gmail.com>> wrote in > Hi > > pá 23. 8. 2019 v 16:32

Monitoring disk space from within the server

Monitoring the available disk space is the topmost thing on the priority for PostgreSQL operation, yet this metric is not available from the SQL level. The attached patch implements a function pg_tablespace_statfs(tblspc) to report disk space numbers per tablespace: # select * from

Re: [proposal] recovery_target "latest"

On 11/8/19 7:00 AM, Grigory Smolkin wrote: On 11/7/19 4:36 PM, Grigory Smolkin wrote: On 11/7/19 12:56 PM, Kyotaro Horiguchi wrote: At Thu, 7 Nov 2019 12:22:28 +0300, Grigory Smolkin wrote in On 11/7/19 8:36 AM, Kyotaro Horiguchi wrote: At Thu, 7 Nov 2019 02:28:39 +0300, Grigory Smolkin

Re: [Proposal] Global temporary tables

On 08.11.2019 10:50, 曾文旌(义从) wrote: In my opinion, it is not a good idea to trigger a btbuild with a select or DML, the cost of which depends on the amount of data in the GTT. IMHO it is better than returning error. Also index will be used only if cost of plan with index will be considered

Re: SPI refactoring

On 2019-Nov-07, Mark Dilger wrote: > From 113d42772be2c2abd71fd142cde9240522f143d7 Mon Sep 17 00:00:00 2001 > From: Mark Dilger > Date: Thu, 7 Nov 2019 07:51:06 -0800 > Subject: [PATCH v1 1/5] Deprecating unused SPI error codes. > > The SPI_ERROR_NOOUTFUNC and SPI_ERROR_CONNECT codes, defined

Re: Global temporary tables

As far as both Robert and Pavel think that aspects of using GTT in parallel queries and at replica should be considered separately. I have prepared simplest version of the patch for GTT which introduces minimal differences with current (local) temporary table. So GTT are stored in private

Re: Refactor parse analysis of EXECUTE command

On 2019-11-08 09:03, Pavel Stehule wrote: Parse analysis of EXECUTE does not access any tables, so if I understood this correctly, this concern doesn't apply here. it should not be true - the subquery can be a expression. Arguments of EXECUTE cannot be subqueries. Minimally on

Re: dropdb --force

pá 8. 11. 2019 v 11:50 odesílatel Amit Kapila napsal: > On Fri, Nov 8, 2019 at 4:13 PM Pavel Stehule > wrote: > > > >>> Did you get a chance to look at the other related patch posted by me > >>> [1]? I have asked it before as well because I think that need to go > >>> before this. We need to

Re: dropdb --force

On Fri, Nov 8, 2019 at 4:13 PM Pavel Stehule wrote: > >>> Did you get a chance to look at the other related patch posted by me >>> [1]? I have asked it before as well because I think that need to go >>> before this. We need to avoid errors to happen after terminating the >>> connections as

Re: dropdb --force

pá 8. 11. 2019 v 6:40 odesílatel Pavel Stehule napsal: > > > pá 8. 11. 2019 v 6:39 odesílatel Amit Kapila > napsal: > >> On Thu, Nov 7, 2019 at 11:29 AM Pavel Stehule >> wrote: >> > čt 7. 11. 2019 v 6:56 odesílatel Amit Kapila >> napsal: >> >> >> >> Okay, no problem. I will pick the previous

Re: [HACKERS] Block level parallel vacuum

Thanks Masahiko san and Dilip for looking into this patch. In previous patch, when *'force_parallel_mode=regress*', I was doing all the vacuum using multiple workers but we should do all the vacuuming using only 1 worker(leader should not participate in vacuuming). So attaching patch for same.

Re: [HACKERS] Block level parallel vacuum

On Tue, Oct 29, 2019 at 12:37 PM Masahiko Sawada wrote: > > I realized that v31-0006 patch doesn't work fine so I've attached the > updated version patch that also incorporated some comments I got so > far. Sorry for the inconvenience. I'll apply your 0001 patch and also > test the total delay

Re: Collation versioning

On Fri, Nov 8, 2019 at 10:20 AM Christoph Berg wrote: > > Re: Laurenz Albe 2019-11-08 > <3c3b9ff84d21acf3188558928249d04db84ea2e9.ca...@cybertec.at> > > #3 is the best proposal, but there is still the need to run > > ALTER INDEX on all affected indexes to keep PostgreSQL from nagging. > >

Re: Collation versioning

On Fri, Nov 8, 2019 at 2:24 AM Thomas Munro wrote: > > On Thu, Nov 7, 2019 at 10:20 PM Julien Rouhaud wrote: > > Attached 4th patch handles default collation. I went with an > > ignore_systempin flag in recordMultipleDependencies. > > Thanks for working on this! I haven't looked closely or

Re: heapam_index_build_range_scan's anyvisible

Hi, On 2019-11-07 09:25:40 -0800, Andres Freund wrote: > On 2019-11-07 17:02:36 +0900, Michael Paquier wrote: > > On Wed, Sep 25, 2019 at 10:24:05PM -0700, Ashwin Agrawal wrote: > > > Thanks for reporting, I did indeed missed out contrib. Please find > > > attached > > > the v2 of the patch

Re: Collation versioning

Re: Laurenz Albe 2019-11-08 <3c3b9ff84d21acf3188558928249d04db84ea2e9.ca...@cybertec.at> > #3 is the best proposal, but there is still the need to run > ALTER INDEX on all affected indexes to keep PostgreSQL from nagging. > Perhaps the situation could be improved with a pg_upgrade option >

Re: [PATCH][DOC] Fix for PREPARE TRANSACTION doc and postgres_fdw message.

Hi Michael, Le 08/11/2019 à 10:05, Michael Paquier a écrit : > On Fri, Nov 08, 2019 at 05:25:52PM +0900, Etsuro Fujita wrote: >> Pushed after modifying the commit message a bit. Thanks! > Should we have more tests for 2PC then? > -- > Michael I don't think so. The support or not of 2PC is on

Re: RFC: split OBJS lines to one object per line

On Thu, Nov 07, 2019 at 12:02:04PM -0500, Tom Lane wrote: > I don't think it'd be a great idea to change parallel_schedule like > that. Independently adding test scripts to the same parallel batch > probably won't end well: you might end up over the concurrency limit, > or the scripts might

Re: [PATCH][DOC] Fix for PREPARE TRANSACTION doc and postgres_fdw message.

On Fri, Nov 08, 2019 at 05:25:52PM +0900, Etsuro Fujita wrote: > Pushed after modifying the commit message a bit. Thanks! Should we have more tests for 2PC then? -- Michael signature.asc Description: PGP signature

Re: pg_upgrade fails with non-standard ACL

On Mon, Oct 28, 2019 at 05:40:44PM +0300, Anastasia Lubennikova wrote: > I added more comments and updated the error message. > Please, feel free to fix them, if you have any suggestions. I have begun looking at this one. + /* REVOKE command must be executed in corresponding database */ + if

Re: Ordering of header file inclusion

On Sat, Nov 2, 2019 at 7:42 AM vignesh C wrote: > > > > Thanks Amit for committing the changes. > I found couple of more inconsistencies, the attached patch includes > the fix for the same. > Thanks for the patch. It seems you've to rebase the patch as it doesn't apply on the latest HEAD. Apart

Re: [PATCH][DOC] Fix for PREPARE TRANSACTION doc and postgres_fdw message.

Hi Gilles, Sorry, I have sent an unfinished email. On Fri, Nov 8, 2019 at 5:20 PM Etsuro Fujita wrote: > On Fri, Nov 8, 2019 at 4:55 PM Gilles Darold wrote: > > Le 07/11/2019 à 11:52, Etsuro Fujita a écrit : > > > On Thu, Nov 7, 2019 at 5:31 PM Kyotaro Horiguchi > > > wrote: > > >> I forgot

Re: [PATCH][DOC] Fix for PREPARE TRANSACTION doc and postgres_fdw message.

Hi Gilles, On Fri, Nov 8, 2019 at 4:55 PM Gilles Darold wrote: > Le 07/11/2019 à 11:52, Etsuro Fujita a écrit : > > On Thu, Nov 7, 2019 at 5:31 PM Kyotaro Horiguchi > > wrote: > >> I forgot to mention that the comment in XACT_EVENT_PRE_PREPARE > >> contains the same mistake and needs more or

Re: [PATCH][DOC] Fix for PREPARE TRANSACTION doc and postgres_fdw message.

Hi Michael-san, On Fri, Nov 8, 2019 at 9:10 AM Michael Paquier wrote: > On Thu, Nov 07, 2019 at 06:40:36PM +0900, Etsuro Fujita wrote: > > On Thu, Nov 7, 2019 at 5:28 PM Kyotaro Horiguchi > > wrote: > >> At Thu, 7 Nov 2019 17:20:07 +0900, Etsuro Fujita > >> wrote in > >>> Only two people

Re: Refactor parse analysis of EXECUTE command

pá 8. 11. 2019 v 8:54 odesílatel Peter Eisentraut < peter.eisentr...@2ndquadrant.com> napsal: > On 2019-11-08 08:13, Pavel Stehule wrote: > > I dug into repository and found that transformExecuteStmt existed at > > the time of implementing PREPARE-EXECUTE statements(28e82066a1) and > >