Merge pull request #13906 from richardhyesungo/docs/upgrade-v1.2

Docs/upgrade v1.2

apps/docs/pages/guides/platform/migrating-and-upgrading-projects.mdx

@@ -12,7 +12,7 @@ In some cases, access to new features require upgrading or migrating your Supaba
 
 ## Upgrade your project
 
-<Admonition type="note">This is only available for projects on the Free plan.</Admonition>
+<Admonition type="note">This is only available for projects on the Free plan. For projects on the Pro plan, please contact support for assistance with upgrading.</Admonition>
 
 When you pause and restore a project, the restored database includes the latest features. This method _does_ include downtime, so be aware that your project will be inaccessible for a short period of time.
 

apps/www/_blog/2023-04-21-whats-new-in-pg-graphql-v1-2.mdx

@@ -15,10 +15,16 @@ thumb: launch-week-6/pggraphql/og-pg-graphql.png
 ---
 
 It's been 4 months since the [1.0.0 release of pg_graphql](https://supabase.com/blog/pg-graphql-v1).
-Since then, we’ve pushed several features to improve the APIs that `pg_graphql` produces. 
+Since then, we’ve pushed several features to improve the APIs that `pg_graphql` produces.
 
 In this article, we’ll walk through those features and show examples of each.
 
+<div className="bg-gray-300 rounded-lg px-6 py-2 italic">
+
+📢 These features are only available on projects with Postgres version `15.1.0.63` or higher. For help with upgrading, please review the [migrating and upgrading projects guide](https://supabase.com/docs/guides/platform/migrating-and-upgrading-projects).
+
+</div>
+
 ### View Support
 
 Prior to `v1.1`, `pg_graphql` would only reflect standard tables. Since then, views, materialized views, and foreign tables are now also reflected in the GraphQL schema.
@@ -26,7 +32,7 @@ Prior to `v1.1`, `pg_graphql` would only reflect standard tables. Since then, vi
 For example:
 
 ```sql
-create view "ProjectOwner" as 
+create view "ProjectOwner" as
   select
     acc.id,
     acc.name
@@ -70,7 +76,7 @@ With associated `Edge` and `Connection` types. That enables querying via:
 }
 ```
 
-Additionally, simple views automatically support mutation events like inserts and updates. You might use these to migrate underlying tables while maintaining backwards compatibility with previous API versions. 
+Additionally, simple views automatically support mutation events like inserts and updates. You might use these to migrate underlying tables while maintaining backwards compatibility with previous API versions.
 
 ## Filtering
 
@@ -109,7 +115,7 @@ to return all `blog`s where the `name` is `null`.
 
 ### **`like`**, **`ilike`**, and **`startsWith`**
 
-Text filtering options in `pg_graphql` have historically been restricted to equality checks. The hesitation was due to concerns about exposing a default filter that is difficult to index. The combination of [citext](https://www.postgresql.org/docs/current/citext.html) and [PGroonga available on the platform](https://supabase.com/docs/guides/database/extensions/pgroonga) solves those scalability risks and enabled us to expand the `StringFilter` with options for `like` `ilike` and `startsWith`. 
+Text filtering options in `pg_graphql` have historically been restricted to equality checks. The hesitation was due to concerns about exposing a default filter that is difficult to index. The combination of [citext](https://www.postgresql.org/docs/current/citext.html) and [PGroonga available on the platform](https://supabase.com/docs/guides/database/extensions/pgroonga) solves those scalability risks and enabled us to expand the `StringFilter` with options for `like` `ilike` and `startsWith`.
 
 ```graphql
 input StringFilter {
@@ -118,7 +124,7 @@ input StringFilter {
   startsWith: String
   like: String
   ilike: String
-} 
+}
 ```
 
 Note that `startsWith` filters should be preferred where appropriate because they can leverage simple B-Tree indexes to improve performance.
@@ -139,7 +145,7 @@ Note that `startsWith` filters should be preferred where appropriate because the
 
 ### GraphQL directives `@skip` and `@include`
 
-The GraphQL spec has evolved over time. Although the spec is clear, it is common for GraphQL servers to selectively omit some chunks of functionality. For example, some frameworks intentionally do not expose an introspection schema as a form of security through obscurity. 
+The GraphQL spec has evolved over time. Although the spec is clear, it is common for GraphQL servers to selectively omit some chunks of functionality. For example, some frameworks intentionally do not expose an introspection schema as a form of security through obscurity.
 
 `pg_graphql` aims to be unopinionated and adhere exactly to the spec. The `@skip` and `@include` directives are part of the [GraphQL core specification](https://spec.graphql.org/October2021/#sec--skip) and are now functional.
 
@@ -198,6 +204,6 @@ The headline features we aim to launch in coming releases of `pg_graphql` includ
 
 ## More pg_graphql
 
-- [Introducing pg_graphql: A GraphQL extension for PostgreSQL](https://supabase.com/blog/pg-graphql) 
+- [Introducing pg_graphql: A GraphQL extension for PostgreSQL](https://supabase.com/blog/pg-graphql)
 - [GraphQL is now available in Supabase](https://supabase.com/blog/graphql-now-available)
 - [pg_graphql v1.0](https://supabase.com/blog/pg-graphql-v1)