Update database name from Cloudberry Database to Apache Cloudberry

[gfphoenix78]

Since Cloudberry was donated to Apache, the database name in version() was renamed from Cloudberry Database to Apache Cloudberry. Some tools or extensions rely on the name to recognize database. This commit renames the database name to adapt the change from Apache Cloudberry.

fix #ISSUE_Number

---

Change logs

Describe your change clearly, including what problem is being solved or what document is being added or updated.

Contributor's checklist

Here are some reminders before you submit your pull request:

• Make sure that your Pull Request has a clear title and commit message. You can take the Git commit template as a reference.
• Sign the Contributor License Agreement as prompted for your first-time contribution (One-time setup).
• Learn the code contribution and doc contribution guides for better collaboration.
• List your communications in the GitHub Issues or Discussions (if has or needed).
• Feel free to ask for the cloudberrydb team to help review and approve.

[my-ship-it]

LGTM

[robertmu]

I have concerns about this PR's changes from "Cloudberry Database" to "Apache Cloudberry". While I understand the motivation to align with the new Apache branding, this change would break compatibility with existing Cloudberry Database installations in production environments.

Issues identified:

1. Version Detection Breaking Change

   • The current code uses regex pattern \(Cloudberry Database ([0-9]+\.[0-9]+\.[0-9]+)[^)]*\) to detect Cloudberry Database
   • Changing this to \(Apache Cloudberry ([0-9]+\.[0-9]+\.[0-9]+)[^)]*\) would cause version detection to fail for all existing Cloudberry Database instances
   • This affects all functionality that depends on version detection

2. Backward Compatibility

   • Many production environments are still running Cloudberry Database
   • These installations return "Cloudberry Database" in their version() output
   • The proposed changes would break cbcopy functionality for these existing deployments

3. Scope of Impact

   • Version detection is used throughout the codebase for feature compatibility checks
   • Breaking version detection would affect data migration operations
   • Could potentially impact production workloads

Suggestion:
Instead of replacing the existing support, I recommend treating Apache Cloudberry as a new database type:

1. Keep the existing Cloudberry Database support
2. Add Apache Cloudberry as a new database type
3. Update version detection logic to handle both types
4. Run the full integration and end-to-end test suite to verify compatibility

This approach would:

• Maintain backward compatibility with existing Cloudberry Database installations
• Add proper support for Apache Cloudberry
• Ensure smooth transition for users
• Prevent disruption to production environments

Please consider revising the PR to implement this more backward-compatible approach. Let me know if you would like specific guidance on implementing these changes. #13

[gfphoenix78]

I have concerns about this PR's changes from "Cloudberry Database" to "Apache Cloudberry". While I understand the motivation to align with the new Apache branding, this change would break compatibility with existing Cloudberry Database installations in production environments.

Issues identified:

1. Version Detection Breaking Change

   • The current code uses regex pattern \(Cloudberry Database ([0-9]+\.[0-9]+\.[0-9]+)[^)]*\) to detect Cloudberry Database
   • Changing this to \(Apache Cloudberry ([0-9]+\.[0-9]+\.[0-9]+)[^)]*\) would cause version detection to fail for all existing Cloudberry Database instances
   • This affects all functionality that depends on version detection

2. Backward Compatibility

   • Many production environments are still running Cloudberry Database
   • These installations return "Cloudberry Database" in their version() output
   • The proposed changes would break cbcopy functionality for these existing deployments

3. Scope of Impact

   • Version detection is used throughout the codebase for feature compatibility checks
   • Breaking version detection would affect data migration operations
   • Could potentially impact production workloads

Suggestion: Instead of replacing the existing support, I recommend treating Apache Cloudberry as a new database type:

1. Keep the existing Cloudberry Database support
2. Add Apache Cloudberry as a new database type
3. Update version detection logic to handle both types
4. Run the full integration and end-to-end test suite to verify compatibility

This approach would:

• Maintain backward compatibility with existing Cloudberry Database installations
• Add proper support for Apache Cloudberry
• Ensure smooth transition for users
• Prevent disruption to production environments

Please consider revising the PR to implement this more backward-compatible approach. Let me know if you would like specific guidance on implementing these changes. #13

The old pattern is still kept. The commit adds new pattern for Apache Cloudberry. Both patterns will be recognized to Cloudberry.

[robertmu]

Handle both Apache Cloudberry and Cloudberry Database by classifying them as CBDB, this approach could lead to issues in the future:

1. Version number conflicts: For example, in [Bug] Error in copy some tables #13 we see Apache Cloudberry 1.6.0, but Cloudberry Database 1.6.0 also exists. These are different database products with the same version number.

2. Catalog differences: Apache Cloudberry and Cloudberry Database likely have different catalogs. By treating them as the same type (CBDB), how can we correctly handle their metadata differences when generating DDL statements?

Are you sure that Apache Cloudberry and Cloudberry Database have exactly the same catalog? If not, we need to identify the differences to ensure our metadata queries work correctly for both databases and can generate appropriate DDL statements for each.

We should identify them as different database types and handle version checks differently in all places where we query metadata and generate DDL statements.