On Wed, Jul 06, 2022 at 09:10:53AM -0400, Bruce Momjian wrote:
> On Tue, Jul 5, 2022 at 07:45:57PM -0700, Noah Misch wrote:
> > On Tue, Jul 05, 2022 at 07:47:52PM -0400, Bruce Momjian wrote:
> > > Yes, I think it is a question of practicality vs. desirability. We are
> > > basically telling
Thomas Munro writes:
> I wonder how much dead code for ancient operating systems we could now
> drop.
+1, it seems like this is the cycle for some housecleaning.
> * prairiedog, macOS 10.4 (vintage system most likely to cause problems)
FWIW, I am expecting to retire prairiedog once the meson
Hi,
In one of my compilations of Postgres, I noted this warning from gcc.
gcc -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Werror=vla -Wendif-labels
-Wmissing-format-attribute -Wimplicit-fallthrough=3 -Wcast-function-type
-Wformat-security -fno-strict-aliasing
I wrote:
> As committed, gen_node_support.pl excludes CallContext and InlineCodeBlock
> from getting unneeded support functions via some very ad-hoc code.
> (Right now, there are some other node types that are handled similarly,
> but I'm looking to drive that set to empty.) After looking at the
As committed, gen_node_support.pl excludes CallContext and InlineCodeBlock
from getting unneeded support functions via some very ad-hoc code.
(Right now, there are some other node types that are handled similarly,
but I'm looking to drive that set to empty.) After looking at the
situation a bit,
We've long avoided building I/O support for utility-statement node
types, mainly because it didn't seem worth the trouble to write and
maintain such code by hand. Now that the automatic node-support-code
generation patch is in, that argument is gone, and it's just a matter
of whether the benefits
On Sun, Jul 10, 2022 at 5:47 AM Ibrar Ahmed wrote:
> I am using "SunOS solaris-vagrant 5.11 11.4.0.15.0 i86pc i386 i86pc",
Hah. So your vagrant image must be from a fairly narrow range of time
when Solaris 11.4 came out with memset_s but didn't yet have
explicit_bzero. That arrived in SRU12 in
On Sat, Jul 9, 2022 at 10:28 AM Thomas Munro wrote:
> On Sat, Jul 9, 2022 at 2:02 PM Ibrar Ahmed wrote:
> > Thanks for looking at that, yes you are right, the attached patch do
> that now
> >
> > if test "$PORTNAME" = "solaris"; then
> >
> >CPPFLAGS="$CPPFLAGS -D_POSIX_PTHREAD_SEMANTICS"
>
On Sun, Jun 26, 2022 at 09:14:56AM -0700, David G. Johnston wrote:
> So leave the "release" behavior implied from the rollback behavior?
>
> On the whole I'm slightly in favor of your proposed wording (mostly due to the
> better fitting of the ROLLBACK command, though at the omission of
Here's some follow-on patches, as I threatened yesterday.
0001 adds some material to nodes/README in hopes of compensating for
a couple of removed comments.
0002 fixes gen_node_support.pl's rather badly broken error reporting.
As it stands, it always says that an error is on line 1 of the
On Sat, Jul 9, 2022, 08:16 Bruce Momjian wrote:
> On Sat, Jul 9, 2022 at 08:06:21AM -0700, David G. Johnston wrote:
> > Maybe invoke the wording from the libpq docs and say:
> >
> > The default database name is the same as the user connection parameter.
> >
> >
>
On Sat, Jul 9, 2022 at 08:06:21AM -0700, David G. Johnston wrote:
> Maybe invoke the wording from the libpq docs and say:
>
> The default database name is the same as the user connection parameter.
>
> https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-PARAMKEYWORDS
>
> That page
On Friday, July 8, 2022, Bruce Momjian wrote:
> On Fri, Jul 8, 2022 at 10:17:11PM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > > On Tue, Jul 5, 2022 at 08:20:25PM -0400, Tom Lane wrote:
> > >> I agree this phrasing needs some work, but "resolved" doesn't seem
> > >> helpful, since
Peter Eisentraut writes:
> On 08.07.22 22:03, Tom Lane wrote:
>> I think this is ready to go (don't forget the catversion bump).
> This is done now, after a brief vpath-shaped scare from the buildfarm
> earlier today.
Doh ... never occurred to me either to try that :-(
On 08.07.22 22:03, Tom Lane wrote:
I think this is ready to go (don't forget the catversion bump).
This is done now, after a brief vpath-shaped scare from the buildfarm
earlier today.
On 01 Jul 2022, at 22:59, Jacob Champion wrote:
>> I added this to httpd a while back:
>>
>> SSL_CLIENT_CERT_RFC4523_CEA
>>
>> It would be good to interoperate.
>
> What kind of interoperation did you have in mind? Are there existing
> tools that want to scrape this information for
On Sat, Jul 9, 2022 at 5:18 AM Dean Rasheed
wrote:
> On Sat, 9 Jul 2022 at 12:24, Zhihong Yu wrote:
> >
> > It seems the code would be more readable if you keep the assignment in
> else block below:
> >
> > + else if (rte->rtekind == RTE_SUBQUERY ||
> > +
On Sat, 9 Jul 2022 at 12:24, Zhihong Yu wrote:
>
> It seems the code would be more readable if you keep the assignment in else
> block below:
>
> + else if (rte->rtekind == RTE_SUBQUERY ||
> +rte->rtekind == RTE_VALUES)
>
On Mon, 13 Dec 2021 at 02:21, Tomas Vondra
wrote:
>
> Hi,
>
> I finally got around to this patch again, focusing mostly on the first
> part that simply returns either 1.0 or 0.0 for Var op Var conditions
> (i.e. the part not really using extended statistics).
>
Just starting to look at this
On Sat, Jul 9, 2022 at 3:28 AM Dean Rasheed
wrote:
> On Wed, 6 Jul 2022 at 15:09, Dean Rasheed
> wrote:
> >
> > I'll post an update in a little while, but first, I found a bug, which
> > revealed a pre-existing bug in transformLockingClause(). I'll start a
> > new thread for that, since it'd be
On Wed, 6 Jul 2022 at 15:09, Dean Rasheed wrote:
>
> I'll post an update in a little while, but first, I found a bug, which
> revealed a pre-existing bug in transformLockingClause(). I'll start a
> new thread for that, since it'd be good to get that resolved
> independently of this patch.
>
On 06.07.2022 20:11, Robert Haas wrote:
On Thu, Mar 31, 2022 at 12:00 PM Julien Rouhaud wrote:
Indeed. Then there is a very simple solution for this particular case as
wal_records counter may only sometime becomes greater but never less.
The corresponding patch is attached.
+1 for this
22 matches
Mail list logo
