On 6/21/21 12:34 PM, Tom Lane wrote:
> Daniel Gustafsson writes:
>> On 21 Jun 2021, at 17:27, Robert Haas wrote:
>>> What will prevent us from forgetting to do something about this again,
>>> a year from now?
>> An entry in a release checklist could perhaps be an idea?
> Yeah, I was wondering i
Daniel Gustafsson writes:
> On 21 Jun 2021, at 17:27, Robert Haas wrote:
>> What will prevent us from forgetting to do something about this again,
>> a year from now?
> An entry in a release checklist could perhaps be an idea?
Yeah, I was wondering if adding an entry to RELEASE_CHANGES would be
> On 21 Jun 2021, at 17:27, Robert Haas wrote:
>
> On Sat, Jun 19, 2021 at 11:45 AM Tom Lane wrote:
>> Hearing no further comments, done that way.
>
> What will prevent us from forgetting to do something about this again,
> a year from now?
An entry in a release checklist could perhaps be an i
Robert Haas writes:
> What will prevent us from forgetting to do something about this again,
> a year from now?
As long as we notice it before 15.0, we can fix it retroactively,
as we just did for 14. For that matter, fixing before 15.1 or
so would likely be Good Enough.
But realistically, how
On Sat, Jun 19, 2021 at 11:45 AM Tom Lane wrote:
> Hearing no further comments, done that way.
What will prevent us from forgetting to do something about this again,
a year from now?
--
Robert Haas
EDB: http://www.enterprisedb.com
I wrote:
> Alvaro Herrera writes:
>> Well, if we do want docs for these macros, then IMO it'd be okay to have
>> them in libpq-fe.h itself rather than SGML. A one-line comment for each
>> would suffice:
> WFM. I'd sort of supposed that the symbol names were self-documenting,
> but you're right
Alvaro Herrera writes:
> On 2021-Jun-18, Tom Lane wrote:
>> I guess one unresolved question is whether we want to mention these in
>> the SGML docs. I vote "no", because it'll raise the maintenance cost
>> noticeably. But I can see an argument on the other side.
> Well, if we do want docs for t
On 2021-Jun-18, Tom Lane wrote:
> Alvaro Herrera writes:
> > So I'm +1 on adding this "feature macro".
>
> Concretely, how about the attached?
Seems OK to me. We can just accumulate any similar ones in the future
nearby.
> (I also got rid of a recently-added
> extra comma. While the compiler
Alvaro Herrera writes:
> So I'm +1 on adding this "feature macro".
Concretely, how about the attached? (I also got rid of a recently-added
extra comma. While the compilers we use might not warn about that,
it seems unwise to assume that no user's compiler will.)
I guess one unresolved question
On 2021-Jun-18, Boris Kolpackov wrote:
> Tom Lane writes:
>
> > I think putting a version number as such in there is a truly
> > horrid idea. However, I could get behind adding a boolean flag
> > that says specifically whether the pipeline feature exists.
> > Then you'd do something like
> >
>
Boris Kolpackov writes:
> Tom Lane writes:
>> I think putting a version number as such in there is a truly
>> horrid idea. However, I could get behind adding a boolean flag
>> that says specifically whether the pipeline feature exists.
> That would be even better, but I agree with what others h
Tom Lane writes:
> I think putting a version number as such in there is a truly
> horrid idea. However, I could get behind adding a boolean flag
> that says specifically whether the pipeline feature exists.
> Then you'd do something like
>
> #ifdef LIBPQ_HAS_PIPELINING
>
> rather than embeddin
Robert Haas writes:
> On Thu, Jun 17, 2021 at 2:34 PM Tom Lane wrote:
>> ... Just because the
>> version-number approach offloads work from us doesn't make it a good
>> idea, because the work doesn't vanish; it will be dumped in the laps
>> of packagers and end users.
> What work? Including an
On Thu, Jun 17, 2021 at 2:34 PM Tom Lane wrote:
> Interesting, but then you have to explain why this is the first time
> that somebody has asked for a version number in libpq-fe.h. Maybe
> all those previous additions were indeed minor enough that the
> problem didn't come up. (Another likely po
On Thu, Jun 17, 2021 at 08:15:42PM +0100, Dagfinn Ilmari Mannsåker wrote:
> Tom Lane writes:
> > Robert Haas writes:
> >> I just went and looked at how exports.txt has evolved over the years.
> >> Since PostgreSQL 8.1, every release except for 9.4 and 11 added at
> >> least one new function to li
Tom Lane writes:
> Robert Haas writes:
>> I just went and looked at how exports.txt has evolved over the years.
>> Since PostgreSQL 8.1, every release except for 9.4 and 11 added at
>> least one new function to libpq. That means in 14 releases we've done
>> something that might break someone's c
Hi,
On 2021-06-17 14:41:40 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I'm not sure I understand why you think that exposing the version number
> > for libpq is such a bad idea?
> > I think it'd be reasonable to add a few more carefully chosen macros to
> > pg_config_ext.h.
>
> The primar
Andres Freund writes:
> I'm not sure I understand why you think that exposing the version number
> for libpq is such a bad idea?
> I think it'd be reasonable to add a few more carefully chosen macros to
> pg_config_ext.h.
The primary problem I've got with that is the risk of confusion
between ser
Robert Haas writes:
> I just went and looked at how exports.txt has evolved over the years.
> Since PostgreSQL 8.1, every release except for 9.4 and 11 added at
> least one new function to libpq. That means in 14 releases we've done
> something that might break someone's compile 12 times. Now mayb
Hi,
On 2021-06-17 13:16:17 -0400, Tom Lane wrote:
> > Then again, why would pg_config.h be absent?
>
> Likely because somebody decided it was a server-side include rather
> than an application-side include.
Which is the right call - pg_config.h can't easily be included in
applications that thems
On Thu, Jun 17, 2021 at 1:16 PM Tom Lane wrote:
> We don't really add major new APIs to libpq very often, so I don't
> find that too compelling. I do find it compelling that user code
> shouldn't embed knowledge about "feature X arrived in version Y".
I just went and looked at how exports.txt ha
> On 17 Jun 2021, at 19:16, Tom Lane wrote:
> A more critical point is that if pg_config is present, it'll likely
> contain the server version, which might not have a lot to do with the
> libpq version. Debian's already shipping things in a way that decouples
> those, and I gather Red Hat is mov
Robert Haas writes:
> On Thu, Jun 17, 2021 at 9:34 AM Tom Lane wrote:
>> I think putting a version number as such in there is a truly
>> horrid idea. However, I could get behind adding a boolean flag
>> that says specifically whether the pipeline feature exists.
> I realize that this kind of fe
On Thu, Jun 17, 2021 at 9:34 AM Tom Lane wrote:
> I think putting a version number as such in there is a truly
> horrid idea. However, I could get behind adding a boolean flag
> that says specifically whether the pipeline feature exists.
> Then you'd do something like
>
> #ifdef LIBPQ_HAS_PIPELIN
Boris Kolpackov writes:
> I am making use of the new pipeline mode added to libpq in
> PostgreSQL 14. At the same time I would still like to support
> older libpq versions by not providing the extended functionality
> that depends on this mode.
Good point.
> The natural way to achieve this in C/
I am making use of the new pipeline mode added to libpq in
PostgreSQL 14. At the same time I would still like to support
older libpq versions by not providing the extended functionality
that depends on this mode.
The natural way to achieve this in C/C++ is to conditionally
enable code that depends
26 matches
Mail list logo
