Alvaro Herrera writes:
> On 2020-Sep-07, Tom Lane wrote:
>> If there were something to be on the warpath about, it's that initdb
>> is pulling in such an obviously backend-only header as that. I wonder
>> if we should refactor to fix that.
> Hmm, if we wanted to clean things up I think we should
On 2020-Sep-07, Tom Lane wrote:
> If there were something to be on the warpath about, it's that initdb
> is pulling in such an obviously backend-only header as that. I wonder
> if we should refactor to fix that.
>
> Quick experimentation says that the symbols initdb actually needs out
> of that
Alvaro Herrera writes:
> On 2020-Sep-07, Tom Lane wrote:
>> I didn't bother tracking down exactly where initdb.c is getting
>> stringinfo.h from, but it clearly does import it somewhere in
>> our rat's nest of headers.
> You can see it here: https://doxygen.postgresql.org/initdb_8c.html
> It's th
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 getting
> > stringinfo.h from, but it clearly
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 getting
> stringinfo.h from, but it clearly does import it somewhere in
> our rat's nest of headers.
You can see it
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 getting
stringinfo.h from, but it clearly does import it somewhere in
our rat's nest of headers.
regards, tom lane
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 included directly with #include
> "lib/strin
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 included directly with #include "lib/stringinfo.h" ?
> That's the right thing to do, yes.
Yeah, if you wa
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 included directly with #include "lib/stringinfo.h" ?
That's the right thing to do, yes.
--
Álvaro Herrerahttps://www
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, n
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, now the code added by commit 8f8154a50
can use pg_get_line_append(
11 matches
Mail list logo
