On Tue, Feb 11, 2025 at 2:29 PM Melanie Plageman <melanieplage...@gmail.com> wrote: > > On Tue, Feb 11, 2025 at 3:10 AM Sergey Tatarintsev > <s.tatarint...@postgrespro.ru> wrote: > > > > 08.02.2025 17:32, Álvaro Herrera пишет: > > > On 2025-Feb-07, Melanie Plageman wrote: > > > > > >> Okay, I've stared at this a bit, and it seems basically fine the way > > >> it is (I might add a bit more whitespace, clean up the commit message, > > >> etc). So I'm interested in committing it. I will admit that having > > >> never committed anything to pgbench, I'm a bit nervous. So, give me a > > >> couple days to work up the nerve. > > > Sounds good. I only wanted to say that I would use PQexecParams() > > > instead of PQexec() in the new function, avoiding the psprintf and > > > pfree, and also that initializing relkind to RELKIND_RELATION is strange > > > and probably unnecessary. > > > > > Let it be so. I made the suggested changes (patch v4 attached) > > I was testing with this with the intent to commit it and noticed that > it does change behavior in one way -- previously if you created an > unlogged table with the same schema as one of the pgbench tables and > then used client-side data generation, it would COPY FREEZE data into > that table. With the patch, it would no longer do that. I can live > with that, but I thought it was worth mentioning.
I am also wondering whether or not adding a pgbench test is appropriate. I don't see any other pgbench tests which test data generation when DDL was done by the user. I'm thinking maybe this is kind of a supported but undocumented use case. In which case maybe we don't want a test for it? - Melanie
