On Tue, Feb 11, 2025 at 2:29 PM Melanie Plageman
<melanieplageman@gmail.com> wrote:
>
> On Tue, Feb 11, 2025 at 3:10 AM Sergey Tatarintsev
> <s.tatarintsev@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
