[Bucardo-general] Possible areas for Bucardo modernization

[David Christensen]

> On Oct 22, 2020, at 12:04 AM, Jon Jensen <jon at endpoint.com> wrote:
> 
> Bucardo developers,
> 
> I have been working on adding large object support for Bucardo, and along the way I made some notes of things we might want to discuss to keep the project alive and kicking, as a good goat should. 🐐
> 
> In no particular order:
> 
> Should we boost the minimum required Perl version? It's still at 5.8.3. It seems crazy not to be able to use the // operator that was introduced in 5.10 almost 13 years ago. The current oldest supported Perl version is 5.30, or in the LTS Linux distros, 5.16.3 in CentOS 7 (after CentOS 6 goes EOL next month). Not a big deal to work around missing // of course, but seems like a new major Bucardo release might be as good a time as any.

I’m fine with making future versions require newer perls; any ongoing development of Bucardo doesn’t erase the older versions/support for older PostgreSQL, and if this introduces things that are easier to work with in modern development I’m all for it.

> Should we remove Drizzle support, since the Drizzle project is long dead?

I have never used this piece; from what I can see in the code there is not a ton required to support this, nor has there been a release since 2012.  If we can clearly remove it from newer code I’d say +1.

> There are some workarounds for DBD::Pg < 2.18.1 that can go away once we require at least that version. It was released in May 2011, so seems like that could be done now.

Same rationale.

> The FAQ still uses the old terminology multi-master, master-slave: https://bucardo.org/Bucardo/FAQ.html - Any objection to replacing that?

Seems reasonable; we can also see about cleaning up any remaining ungulate references as well (if any).  Cute, but confusing to anyone not versed in the origination of the code.

> Are there any TODO comments we can get rid of in the code? Some have been there forever. If they should stay, that's fine, just looking for the case where time has made some no longer needed.

Would have to review some specifics to speak more clearly on this.

> A little code question: Around line 7081 of Bucardo.pm this "binarycols" array seems unused, and bytea data is converted to base64, so is this needed?
> 
>> ## This is used to bind_param these as binary during inserts and updates
>> push @{$g->{binarycols}}, $colinfo->{$colname}{order};
> 

This appears to be a holdover from pre-5.x behavior.  I would assume that this (being the only current reference) could be removed/refactored.

> Finally, old Postgres version support:
> 
> I was going to suggest we consider increasing the minimum Postgres version supported, but perhaps this is an area where we should be very conservative because a major use case for Bucardo is for upgrades, and old database that have been neglected is where it really shines and the latest Postgres features are not available.

Agreed that this is one of the existing rationales for Bucardo’s current existence.  That said, removing support from future Bucardo versions does not eliminate the old ones from the internet, so previous functionality would be available.  My personal feelings are that 8.x systems are increasingly rare, so targeting 9.x+ is a decent baseline.  (And really, anything < 9.2 doesn’t seem to come up much in my personal experience, so if you held a curved horn to my head and demanded earliest version support I’d say 9.2.)

> But for the sake of discussion I saw:
> 
> * workaround for clock_timestamp() not existing until 8.2
> 
> * array_agg reimplemented for < 8.4
> 
> * a few checks for 8.3, 9.0, 9.2
> 
> Yet maybe we should leave most of those alone.

I’m fine leaving them in if we aren’t reworking any code sections for new features.  If we do institute a cutoff for Pg versions, we should detect that early and suggest an earlier version of Bucardo (and point to downloads) in that case.

> Please let me know if any of this resonates!
> 
> Thanks,
> Jon

David
--
David Christensen
Senior Software and Database Engineer
End Point Corporation
david at endpoint.com
785-727-1171




--
David Christensen
Senior Software and Database Engineer
End Point Corporation
david at endpoint.com
785-727-1171


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://bucardo.org/pipermail/bucardo-general/attachments/20201023/ba09e22c/attachment.sig>