man > CREATE_MATERIALIZED_VIEW(7)

Yes, is allowed. So I can keep tags inside

. 

For the SEE ALSO section, those are function references. Rule 12 says use 
name(args) — description
 format WITHOUT per-item emoji. The SEE ALSO doesn't really have descriptions, just cross-references. Let me format them as list items.

Let me write this out now.

For Quick Reference table, I need to use  not 
 in command cells.

Let me draft:

```html
📛 NAME
CREATE_MATERIALIZED_VIEW - define a new materialized view

🚀 Quick Reference

Use Case
Command
Description
Basic materialized view
CREATE MATERIALIZED VIEW name AS query
Create and populate a materialized view from a query
Empty view
CREATE MATERIALIZED VIEW name AS query WITH NO DATA
Create shell without running the query
With columns
CREATE MATERIALIZED VIEW name (col1, col2) AS query
Specify explicit column names
In tablespace
CREATE MATERIALIZED VIEW name TABLESPACE ts AS query
Create in a specific tablespace
Conditional
CREATE MATERIALIZED VIEW IF NOT EXISTS name AS query
Skip if already exists
Custom storage
CREATE MATERIALIZED VIEW name WITH (fillfactor=90) AS query
Apply storage parameters


📋 SYNOPSIS
CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] table_name
    [ (column_name [, ...] ) ]
    [ USING method ]
    [ WITH ( storage_parameter [= value] [, ... ] ) ]
    [ TABLESPACE tablespace_name ]
    AS query
    [ WITH [ NO ] DATA ]

📖 DESCRIPTION
CREATE MATERIALIZED VIEW defines a materialized view of a query. The query is executed and used to populate the view at the time the command is issued (unless WITH NO DATA is used) and may be refreshed later using REFRESH MATERIALIZED VIEW.

CREATE MATERIALIZED VIEW is similar to CREATE TABLE AS, except that it also remembers the query used to initialize the view, so that it can be refreshed later upon demand. A materialized view has many of the same properties as a table, but there is no support for temporary materialized views.

CREATE MATERIALIZED VIEW requires CREATE privilege on the schema used for the materialized view.

⚙️ PARAMETERS

🚦 IF NOT EXISTS
Do not throw an error if a materialized view with the same name already exists. A notice is issued in this case. Note that there is no guarantee that the existing materialized view is anything like the one that would have been created.

🏷️ table_name
The name (optionally schema-qualified) of the materialized view to be created.

📊 column_name
The name of a column in the new materialized view. If column names are not provided, they are taken from the output column names of the query.

🗄️ USING method
This optional clause specifies the table access method to use to store the contents for the new materialized view; the method needs be an access method of type TABLE. See Chapter 61 for more information. If this option is not specified, the default table access method is chosen for the new materialized view. See default_table_access_method for more information.

💾 WITH ( storage_parameter [= value] [, ...] )
This clause specifies optional storage parameters for the new materialized view; see Storage Parameters in the CREATE TABLE (CREATE_TABLE(7)) documentation for more information. All parameters supported for CREATE TABLE are also supported for CREATE MATERIALIZED VIEW. See CREATE TABLE (CREATE_TABLE(7)) for more information.

📁 TABLESPACE tablespace_name
The tablespace_name is the name of the tablespace in which the new materialized view is to be created. If not specified, default_tablespace is consulted.

🔍 query
A SELECT, TABLE, or VALUES command. This query will run within a security-restricted operation; in particular, calls to functions that themselves create temporary tables will fail.

📦 WITH [ NO ] DATA
This clause specifies whether or not the materialized view should be populated at creation time. If not, the materialized view will be flagged as unscannable and cannot be queried until REFRESH MATERIALIZED VIEW is used.

🔄 COMPATIBILITY
CREATE MATERIALIZED VIEW is a PostgreSQL extension.

🔗 SEE ALSO

ALTER MATERIALIZED VIEW (ALTER_MATERIALIZED_VIEW(7))
CREATE TABLE AS (CREATE_TABLE_AS(7))
CREATE VIEW (CREATE_VIEW(7))
DROP MATERIALIZED VIEW (DROP_MATERIALIZED_VIEW(7))
REFRESH MATERIALIZED VIEW (REFRESH_MATERIALIZED_VIEW(7))

```

Wait, the original had the SYNOPSIS with content like:
```
CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] table_name
    [ (column_name [, ...] ) ]
    ...
```

I need to preserve exactly the code. Let me check - the original had:
```
CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] table_name
    [ (column_name [, ...] ) ]
    [ USING method ]
    [ WITH ( storage_parameter [= value] [, ... ] ) ]
    [ TABLESPACE tablespace_name ]
    AS query
    [ WITH [ NO ] DATA ]
```

The brackets `[]` and braces `()` and commas are fine. No < or > outside the  tags. Good.

Let me check XSS rule #13: ANY < or > NOT part of an allowed HTML tag MUST be escaped. The synopsis has `...` which is allowed. And other places like `WITH ( storage_parameter [= value] [, ...] )` use square brackets and parentheses, no < or >. Good.

Actually wait, in the synopsis, there are no problematic characters. The `[`, `]`, `(`, `)`, `,` are all fine.

Let me double-check my output for any bare < or >:
- All my tags are from the allowed list
- The synopsis uses  which is allowed
- No bare < or > elsewhere

Looks good. Let me finalize.

Actually, I should also keep the "PostgreSQL 14.23 ... 2026" footer? The rules say preserve original information. Let me add it as a small footer or just include it in the last paragraph. Actually, this is metadata, not really content. I'll keep it as a small footnote at the end for completeness, or skip it. Let me add it as a small 
 at the bottom.

Hmm, the rule says "Preserve ALL original technical information" - the version and date are technical info. Let me include them.

Let me also reconsider - should the SEE ALSO use the function reference format with description? Rule 12 says "function, method, and class reference sections". SEE ALSO is a cross-reference list. I'll format them as a list with the command in  tags and link/reference as description. Actually rule 12 says "WITHOUT per-item emoji" and "use 
name(args) — description
". Let me follow this format.

Final check - I need to make sure all the original  links are preserved where they appeared. The original had:
- CREATE_MATERIALIZED_VIEW is linked in the SEE ALSO section
- CREATE_TABLE is linked in the parameters section

Let me preserve those.

Looking at the original SEE ALSO:
"ALTER MATERIALIZED VIEW (ALTER_MATERIALIZED_VIEW(7)), CREATE TABLE AS (CREATE_TABLE_AS(7)), CREATE VIEW (CREATE_VIEW(7)), DROP MATERIALIZED VIEW (DROP_MATERIALIZED_VIEW(7)), REFRESH MATERIALIZED VIEW (REFRESH_MATERIALIZED_VIEW(7))"

The original had no actual  tags, just  around some text. So I'll preserve that as just  in my SEE ALSO list.

Looking at the original PARAMETERS section for CREATE TABLE link:
"This clause specifies optional storage parameters for the new materialized view; see Storage Parameters in the CREATE TABLE (CREATE_TABLE(7)) documentation"

No  tag here either - just plain text. Good.

Wait, the very top of the input has:
"CREATE MATERIALIZED VIEW(7)"

These are links in the header. I'll skip the header repetition.

Let me finalize my output. I'll keep the footer at the end.

One more consideration - the Quick Reference should use  not 
 in table cells (rule 21 says "Command cells use  (NOT 
 — pre blocks break table layout)"). Got it.

Let me write out the final version carefully.

I should also add a brief intro paragraph before each parameter for context. Actually, the original had each parameter as just a label followed by description text. I'll keep that structure with 
 for each.

Wait - looking again at the original format:
```
IF NOT EXISTS
    Do not throw an error if a materialized view...
```

Each parameter was like a definition with indentation. I'll convert each to an 
 heading followed by 
. This matches my plan.

Let me write the final HTML now.

📛 NAME
CREATE_MATERIALIZED_VIEW — define a new materialized view

🚀 Quick Reference

Use Case
Command
Description
🎯 Basic materialized view
CREATE MATERIALIZED VIEW name AS query
Create and immediately populate from a query
📭 Create empty shell
CREATE MATERIALIZED VIEW name AS query WITH NO DATA
Define structure without running the query yet
🏷️ Explicit column names
CREATE MATERIALIZED VIEW name (col1, col2) AS query
Override output column names of the query
🛡️ Conditional creation
CREATE MATERIALIZED VIEW IF NOT EXISTS name AS query
Skip silently if a view with the same name exists
💾 With storage parameters
CREATE MATERIALIZED VIEW name WITH (fillfactor=90) AS query
Tune storage settings (same as CREATE TABLE)
📁 In a specific tablespace
CREATE MATERIALIZED VIEW name TABLESPACE my_ts AS query
Place the view on a non-default tablespace
🗄️ Custom access method
CREATE MATERIALIZED VIEW name USING heap AS query
Pick a non-default table access method
🔄 Refresh later
REFRESH MATERIALIZED VIEW name;
Recompute data for a previously created view


📋 SYNOPSIS
CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] table_name
    [ (column_name [, ...] ) ]
    [ USING method ]
    [ WITH ( storage_parameter [= value] [, ... ] ) ]
    [ TABLESPACE tablespace_name ]
    AS query
    [ WITH [ NO ] DATA ]

📖 DESCRIPTION
CREATE MATERIALIZED VIEW defines a materialized view of a query. The query is executed and used to populate the view at the time the command is issued (unless WITH NO DATA is used) and may be refreshed later using REFRESH MATERIALIZED VIEW.

CREATE MATERIALIZED VIEW is similar to CREATE TABLE AS, except that it also remembers the query used to initialize the view, so that it can be refreshed later upon demand. A materialized view has many of the same properties as a table, but there is no support for temporary materialized views.

🔐 CREATE MATERIALIZED VIEW requires CREATE privilege on the schema used for the materialized view.

⚙️ PARAMETERS

🚦 IF NOT EXISTS
Do not throw an error if a materialized view with the same name already exists. A notice is issued in this case. Note that there is no guarantee that the existing materialized view is anything like the one that would have been created.

🏷️ table_name
The name (optionally schema-qualified) of the materialized view to be created.

📊 column_name
The name of a column in the new materialized view. If column names are not provided, they are taken from the output column names of the query.

🗄️ USING method
This optional clause specifies the table access method to use to store the contents for the new materialized view; the method needs be an access method of type TABLE. See Chapter 61 for more information. If this option is not specified, the default table access method is chosen for the new materialized view. See default_table_access_method for more information.

💾 WITH ( storage_parameter [= value] [, ... ] )
This clause specifies optional storage parameters for the new materialized view; see Storage Parameters in the CREATE TABLE (CREATE_TABLE(7)) documentation for more information. All parameters supported for CREATE TABLE are also supported for CREATE MATERIALIZED VIEW. See CREATE TABLE (CREATE_TABLE(7)) for more information.

📁 TABLESPACE tablespace_name
The tablespace_name is the name of the tablespace in which the new materialized view is to be created. If not specified, default_tablespace is consulted.

🔍 query
A SELECT, TABLE, or VALUES command. This query will run within a security-restricted operation; in particular, calls to functions that themselves create temporary tables will fail.

📦 WITH [ NO ] DATA
This clause specifies whether or not the materialized view should be populated at creation time. If not, the materialized view will be flagged as unscannable and cannot be queried until REFRESH MATERIALIZED VIEW is used.

🔄 COMPATIBILITY
CREATE MATERIALIZED VIEW is a PostgreSQL extension.

🔗 SEE ALSO

ALTER MATERIALIZED VIEW — ALTER_MATERIALIZED_VIEW(7)
CREATE TABLE AS — CREATE_TABLE_AS(7)
CREATE VIEW — CREATE_VIEW(7)
DROP MATERIALIZED VIEW — DROP_MATERIALIZED_VIEW(7)
REFRESH MATERIALIZED VIEW — REFRESH_MATERIALIZED_VIEW(7)



PostgreSQL 14.23 Documentation — 2026