az postgres flexible-server parameter list: doesn't show actual value by default

[jmealo]

Describe the bug

az postgres flexible-server parameter list --output=table
This only provides the default value and allowed value but not the ACTUAL value. If you're greping this can be a real pain.

Additionally, it switches between TRUE FALSE and true false

In JSON mode, booleans are not booleans, they're uppercase strings.

Related command

az postgres flexible-server parameter list

Errors

N/A

Issue script & Debug output

Nonsensical default columns (actual value missing):

az postgres flexible-server parameter list --resource-group application --server-name production-intel-db-2 --output=table
Name                                           DataType     DefaultValue                    Source          AllowedValues

Inconsistent boolean values:

  {
    "allowedValues": "true, false",
    "dataType": "Boolean",
    "defaultValue": "false",
    "description": "Denotes if pgBouncer service is enabled.",
    "documentationLink": "https://www.pgbouncer.org/config.html",
    "id": "<redacted>",
    "isConfigPendingRestart": false,
    "isDynamicConfig": true,
    "isReadOnly": false,
    "name": "pgbouncer.enabled",
    "value": "TRUE"
  },

Expected behavior

• To show the actual value by default.
• To use booleans consistently.
• Someone to test the DX before shipping.

Environment Summary

{
  "azure-cli": "2.73.0",
  "azure-cli-core": "2.73.0",
  "azure-cli-telemetry": "1.1.0",
  "extensions": {
    "aks-preview": "18.0.0b36"
  }
}

Additional context

No response

[azure-client-tools-bot-prd]

Hi @jmealo,

2.73.0 is not the latest Azure CLI(2.77.0).

If you haven't already attempted to do so, please upgrade to the latest Azure CLI version by following https://learn.microsoft.com/en-us/cli/azure/update-azure-cli.

[yonzhan]

Thank you for opening this issue, we will look into it.

[microsoft-github-policy-service]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @gbowerman, @jasomaning, @nachoalonsoportillo.

[nachoalonsoportillo]

@jmealo, you can always specify a --query to control table and TSV formats. The table layout you're seeing is the one this command uses by default, which might not accommodate your specific needs.

I recommend you to use something like the following:

az postgres flexible-server parameter list --resource-group your-resource-group --server your-server --query '[].{ColumnForName:name, ColumnForValue:value}' --output table

That way you can control which properties you want to project and if you want to rename their headers with whatever alias you consider convenient.

Thanks!

[nachoalonsoportillo]

As for the server parameters of Boolean data type, starting with PG18 we've set their allowed values to on|off. The only Boolean server parameter which is inconsistently allowing true|false is pgbouncer.enabled.

In the future, we're planning to change the behavior of Boolean server parameters so that they behave like Boolean GUCs in PostgreSQL. That is: they accept 1, true, yes, and on as synonyms for enablement. And 0, false, no, and off as synonyms for disablement.

Indeed, for server parameters of Boolean data type, we support any of the two allowed values using any casing. If you override a Boolean server parameter, we store the passed value with the casing you provide.

[jmealo]

@nachoalonsoportillo Thanks for the quick response.

I'd like to emphasize that this isn't about finding workarounds - this appears to be a fundamental design issue affecting core functionality. The current behavior where actual values are excluded by default seems counterintuitive for most use cases.

Additionally, we have only set values using the Portal, so the Portal apparently sets booleans to uppercase strings? 🤔

Impact experienced:
This issue caused significant confusion during a recent Azure-initiated restart that took hours to resolve. The discrepancy between portal and CLI values made troubleshooting more difficult when time was critical.

Specific concerns:

1. CLI output format: When using grep without column labels, users naturally expect the first value to be the actual current value. Having actual values excluded creates a poor user experience.

2. Inconsistency: The mismatch between portal and CLI values undermines confidence in the tooling.

3. JSON format issues: The JSON format problems that should also be addressed. If the data type is boolean, the value should be a boolean, not an upper case string.

User expectations:
When querying a specific instance via CLI, users typically want to see current/actual values. Default and allowed values are better suited for documentation or help commands.

Broader context:
This connects to larger usability challenges with the configuration system, including the need for manual tuning of memory/CPU settings after upgrades/downgrades, which reduces the value proposition of managed services.

Would it be possible to:

• Make actual values the default output?
• Add a flag for users who specifically want default/allowed values?
• Ensure CLI and portal consistency?
• Address the JSON formatting issues?

These changes would significantly improve the user experience and reduce operational friction.

@gbowerman Hello again 😅! I'd appreciate if this could be reconsidered rather than closed quickly, as these issues significantly impact operational workflows. My entire team just assumed Azure CLI and Portal don't match due to collective trauma with Azure tooling.