| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Postgres bugs <pgsql-bugs(at)postgresql(dot)org>, Rainer Orth <ro(at)CeBiTec(dot)Uni-Bielefeld(dot)DE> |
| Subject: | Re: Conflicting declarations for b64_encode etc. on Solaris 11.4 Beta |
| Date: | 2018-03-01 00:55:10 |
| Message-ID: | 20180301005510.GB1178@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Wed, Feb 28, 2018 at 06:37:27PM -0500, Tom Lane wrote:
> And on top of that, there's src/common/base64.c with again almost the
> same functionality. But refactoring to fix that would be a bit invasive
> and not something to back-patch. I think what you did here is appropriate
> as a minimal portability fix. Maybe later somebody will look into
> removing the duplication, as a HEAD-only improvement.
Thanks for pushing the patch.
base64.c ignores some whitespace handling, which is in line with what
the RFCs of SCRAM expect when doing conversion of the data exchanged in
the protocol so that's a bit more different than the other
implementations. Maybe that's worth refactoring, still I am not
completely convinced that we have much to gain from such a move either.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Praveen Kumar | 2018-03-01 06:41:59 | Re: How to avoid trailing zero (after decimal point) for numeric type column |
| Previous Message | Euler Taveira | 2018-03-01 00:21:51 | Re: BUG #15067: Documentation or behaviour bug with autovacuum thresholds? |