fix: Fix minor format errors in the Postgrest aggregate function article (#21735)

Fix format

apps/www/_blog/2024-02-29-postgrest-aggregate-functions.mdx

@@ -194,7 +194,7 @@ Because spreading columns brings them to the top-level, they are treated as colu
 
 ## Staying Safe with Aggregate Functions
 
-Now that we’ve gone through a few examples of how to use aggregate functions, it’s important to discuss how to _safely_ use aggregate functions in your application. Because of the potential performance risks with aggregate functions, we have **[disabled** aggregate functions by default](https://postgrest.org/en/stable/references/configuration.html#db-aggregates-enabled). Only after reviewing the risks and ensuring appropriate safeguards are in place should you enable this feature. On Supabase, you can enable it by modifying the PostgREST connection role and then reloading the server configuration, like so:
+Now that we’ve gone through a few examples of how to use aggregate functions, it’s important to discuss how to _safely_ use aggregate functions in your application. Because of the potential performance risks with aggregate functions, we have [**disabled** aggregate functions by default](https://postgrest.org/en/stable/references/configuration.html#db-aggregates-enabled). Only after reviewing the risks and ensuring appropriate safeguards are in place should you enable this feature. On Supabase, you can enable it by modifying the PostgREST connection role and then reloading the server configuration, like so:
 
 {/* prettier-ignore */}
 ```sql
@@ -208,7 +208,7 @@ For example, imagine our `movies` table from before has twenty million rows. If
 
 Even worse, imagine that someone with bad intentions wants to do bad things to your innocent server: It could be relatively simple for the attacker to bombard your server with expensive aggregation queries, preventing your server from having the capacity to deal with legitimate traffic, a form of denial-of-service attack.
 
-One strategy for preventing potential performance issues is using the `[pg_plan_filter_module](https://github.com/pgexperts/pg_plan_filter)` . Using this extension, you can set an upper limit on the _cost_ of queries that PostgREST will run.
+One strategy for preventing potential performance issues is using the [`pg_plan_filter_module`](https://github.com/pgexperts/pg_plan_filter). Using this extension, you can set an upper limit on the _cost_ of queries that PostgREST will run.
 
 {/* prettier-ignore */}
 ```sql