On Wed, Jan 13, 2021 at 10:11:54PM -0500, Tom Lane wrote:
> Should the CF entry for this be closed? The cfbot is still trying to
> apply the patch, and unsurprisingly failing.
Yes, I was going to close it once I was sure that the buildfarm had
nothing to say. Done now.
--
Michael
Bruce Momjian writes:
> On Thu, Jan 14, 2021 at 11:17:40AM +0900, Michael Paquier wrote:
>> Thanks, Sehrope. I have reviewed the code this morning and fixed
>> that, adjusted a couple of elog() strings I found inconsistent after
>> review and ran pgindent. And applied it.
> Thanks. All my key
On Thu, Jan 14, 2021 at 11:17:40AM +0900, Michael Paquier wrote:
> On Wed, Jan 13, 2021 at 10:00:49AM -0500, Sehrope Sarkuni wrote:
> > The length functions in src/common/hex.c should cast srclen to uint64 prior
> > to the shift. The current hex_enc_len(...) in encode.c performs such a
> > cast.
>
On Wed, Jan 13, 2021 at 10:00:49AM -0500, Sehrope Sarkuni wrote:
> The length functions in src/common/hex.c should cast srclen to uint64 prior
> to the shift. The current hex_enc_len(...) in encode.c performs such a
> cast.
Thanks, Sehrope. I have reviewed the code this morning and fixed
that,
The length functions in src/common/hex.c should cast srclen to uint64 prior
to the shift. The current hex_enc_len(...) in encode.c performs such a
cast.
diff --git a/src/common/hex.c b/src/common/hex.c
index 0123c69697..e87aa1fd7f 100644
--- a/src/common/hex.c
+++ b/src/common/hex.c
@@ -178,7
On Tue, Jan 12, 2021 at 01:13:00PM -0500, Bruce Momjian wrote:
> Thanks for you work on this. Looks good.
I have been looking again at this patch again for a couple of hours
this morning to double-check if I have not missed anything, and I
think that we should be in good shape. This still needs
On Tue, Jan 12, 2021 at 11:26:51AM +0900, Michael Paquier wrote:
> The two only things that were not present are the set of checks for
> overflows, and the adjustments for varlena.c. The first point makes
> the code of encode.c safer, as previously the code would issue a FATAL
> *after* writing
On Mon, Jan 11, 2021 at 11:27:30AM -0500, Bruce Momjian wrote:
> Sure, I realize the elog/pg_log is odd, but the alternatives seem worse.
I guess that it depends on the use cases. If there is no need to
worry about shared libraries, elog/pg_log would do just fine.
> You can take ownership of my
On Mon, Jan 11, 2021 at 04:45:14PM +0900, Michael Paquier wrote:
> On Wed, Jan 06, 2021 at 08:58:23AM -0500, Bruce Momjian wrote:
> > Fine. Do you want to add the overflow to the patch I posted, for all
> > encoding types?
>
> Yeah. It looks that it would be good to be consistent as well for
>
On Wed, Jan 06, 2021 at 08:58:23AM -0500, Bruce Momjian wrote:
> Fine. Do you want to add the overflow to the patch I posted, for all
> encoding types?
Yeah. It looks that it would be good to be consistent as well for
escape case, so as it is possible to add a dstlen argument to struct
On Wed, Jan 6, 2021 at 01:10:28PM +0900, Michael Paquier wrote:
> > It was very confusing, and this attached patch fixes all of that. I
> > also added the pg_ prefix you suggrested. If we want to add dstlen to
> > all the functions, we have to do it for all types --- not sure it is
> > worth
On Tue, Jan 05, 2021 at 12:21:09PM -0500, Bruce Momjian wrote:
> Well, if the backend uses /common for hex like I suggested, and like we
> do now, it has to match the function signatures of bytea and esc, see
> struct pg_encoding. I don't see the point in changing those.
Not necessarily with
On Tue, Jan 5, 2021 at 08:54:11PM +1300, Thomas Munro wrote:
> On Tue, Jan 5, 2021 at 4:47 PM Bruce Momjian wrote:
> > ... let's see how it likes this version.
>
> cfbot ideally processes a new patch fairly quickly but I didn't think
> of ".diff.gz" when writing the regexp to recognise patch
On Tue, Jan 5, 2021 at 03:47:59PM +0900, Michael Paquier wrote:
> On Mon, Jan 04, 2021 at 10:47:39PM -0500, Bruce Momjian wrote:
> > I can see the value of passing the destination length to the hex
> > functions, and I think you have to pass the src length to pg_hex_encode
> > since the input can
On Tue, Jan 5, 2021 at 4:47 PM Bruce Momjian wrote:
> ... let's see how it likes this version.
cfbot ideally processes a new patch fairly quickly but I didn't think
of ".diff.gz" when writing the regexp to recognise patch files. I
just tweaked the relevant regexp and it's building your patch
On Mon, Jan 04, 2021 at 10:47:39PM -0500, Bruce Momjian wrote:
> I can see the value of passing the destination length to the hex
> functions, and I think you have to pass the src length to pg_hex_encode
> since the input can be binary. I assume the pg_hex_decode doesn't need
> the source length
On Sat, Jan 2, 2021 at 02:25:33PM +0900, Michael Paquier wrote:
> > Let me get my patch building on the cfbot and then I will address each
> > of these. I am trying to do one stage at a time since I am still
> > learning the process. Thanks.
>
> No problem. On my end, this stuff has been
On Fri, Jan 01, 2021 at 03:06:13PM -0500, Bruce Momjian wrote:
> Thanks. I had to learn how to squash my commits into a new branch and
> then generate a format-patch on that:
>
> https://bugsdb.com/_en/debug/8b648ec395b86be32efa9629cb006d74
>
> I wanted to see how the cfbot liked my
On Thu, Dec 31, 2020 at 03:10:29PM +0900, Michael Paquier wrote:
> On Wed, Dec 30, 2020 at 08:22:07PM -0500, Bruce Momjian wrote:
> > So, I am learning this cfbot thing. Seems I need -M100% to disable
> > rename detection for diffs to work with cfbot --- makes sense.
>
> A good way to make sure
On Wed, Dec 30, 2020 at 08:22:07PM -0500, Bruce Momjian wrote:
> So, I am learning this cfbot thing. Seems I need -M100% to disable
> rename detection for diffs to work with cfbot --- makes sense.
A good way to make sure that a patch format is correct for the CF bot
would be to use "git
On Wed, Dec 30, 2020 at 07:35:57PM -0500, Bruce Momjian wrote:
> I now understand the wisdom of moving the remaining hex functions to
> /common. I know someone already suggested that, and the attached patch
> does this.
>
> I will add the attached patch to the commitfest so I can get cfbot
>
I now understand the wisdom of moving the remaining hex functions to
/common. I know someone already suggested that, and the attached patch
does this.
I will add the attached patch to the commitfest so I can get cfbot
testing.
--
Bruce Momjian https://momjian.us
EnterpriseDB
22 matches
Mail list logo
