@@ -196,106 +196,7 @@ ingestion progress and debugging related issues, see [Troubleshooting](/ops/trou
196
196
197
197
## Known limitations
198
198
199
- ### Schema changes
200
-
201
- {{< include-md file="shared-content/schema-changes-in-progress.md" >}}
202
-
203
- {{% schema-changes %}}
204
-
205
- ### Publication membership
206
-
207
- PostgreSQL's logical replication API does not provide a signal when users remove
208
- tables from publications. Because of this, Materialize relies on periodic checks
209
- to determine if a table has been removed from a publication, at which time it
210
- generates an irrevocable error, preventing any values from being read from the
211
- table.
212
-
213
- However, it is possible to remove a table from a publication and then re-add it
214
- before Materialize notices that the table was removed. In this case, Materialize
215
- can no longer provide any consistency guarantees about the data we present from
216
- the table and, unfortunately, is wholly unaware that this occurred.
217
-
218
- To mitigate this issue, if you need to drop and re-add a table to a publication,
219
- ensure that you remove the table/subsource from the source _ before_ re-adding it
220
- using the [ ` DROP SOURCE ` ] ( /sql/drop-source/ ) command.
221
-
222
- ### Supported types
223
-
224
- Materialize natively supports the following PostgreSQL types (including the
225
- array type for each of the types):
226
-
227
- <ul style =" column-count : 3 " >
228
- <li ><code >bool</code ></li >
229
- <li ><code >bpchar</code ></li >
230
- <li ><code >bytea</code ></li >
231
- <li ><code >char</code ></li >
232
- <li ><code >date</code ></li >
233
- <li ><code >daterange</code ></li >
234
- <li ><code >float4</code ></li >
235
- <li ><code >float8</code ></li >
236
- <li ><code >int2</code ></li >
237
- <li ><code >int2vector</code ></li >
238
- <li ><code >int4</code ></li >
239
- <li ><code >int4range</code ></li >
240
- <li ><code >int8</code ></li >
241
- <li ><code >int8range</code ></li >
242
- <li ><code >interval</code ></li >
243
- <li ><code >json</code ></li >
244
- <li ><code >jsonb</code ></li >
245
- <li ><code >numeric</code ></li >
246
- <li ><code >numrange</code ></li >
247
- <li ><code >oid</code ></li >
248
- <li ><code >text</code ></li >
249
- <li ><code >time</code ></li >
250
- <li ><code >timestamp</code ></li >
251
- <li ><code >timestamptz</code ></li >
252
- <li ><code >tsrange</code ></li >
253
- <li ><code >tstzrange</code ></li >
254
- <li ><code >uuid</code ></li >
255
- <li ><code >varchar</code ></li >
256
- </ul >
257
-
258
- Replicating tables that contain ** unsupported [ data types] ( /sql/types/ ) ** is
259
- possible via the ` TEXT COLUMNS ` option. The specified columns will be treated
260
- as ` text ` , and will thus not offer the expected PostgreSQL type features. For
261
- example:
262
-
263
- * [ ` enum ` ] : the implicit ordering of the original PostgreSQL ` enum ` type is not
264
- preserved, as Materialize will sort values as ` text ` .
265
-
266
- * [ ` money ` ] : the resulting ` text ` value cannot be cast back to e.g. ` numeric ` ,
267
- since PostgreSQL adds typical currency formatting to the output.
268
-
269
- ### Truncation
270
-
271
- Tables replicated into Materialize should not be truncated. If a table is
272
- truncated while replicated, the whole source becomes inaccessible and will not
273
- produce any data until it is recreated. Instead, remove all rows from a table
274
- using an unqualified ` DELETE ` .
275
-
276
- ``` mzsql
277
- DELETE FROM t;
278
- ```
279
-
280
- ### Inherited tables
281
-
282
- When using [ PostgreSQL table inheritance] ( https://www.postgresql.org/docs/current/tutorial-inheritance.html ) ,
283
- PostgreSQL serves data from ` SELECT ` s as if the inheriting tables' data is also
284
- present in the inherited table. However, both PostgreSQL's logical replication
285
- and ` COPY ` only present data written to the tables themselves, i.e. the
286
- inheriting data is _ not_ treated as part of the inherited table.
287
-
288
- PostgreSQL sources use logical replication and ` COPY ` to ingest table data, so
289
- inheriting tables' data will only be ingested as part of the inheriting table,
290
- i.e. in Materialize, the data will not be returned when serving ` SELECT ` s from
291
- the inherited table.
292
-
293
- You can mimic PostgreSQL's ` SELECT ` behavior with inherited tables by creating a
294
- materialized view that unions data from the inherited and inheriting tables
295
- (using ` UNION ALL ` ). However, if new tables inherit from the table, data from
296
- the inheriting tables will not be available in the view. You will need to add
297
- the inheriting tables via ` ADD SUBSOURCE ` and create a new view (materialized or
298
- non-) that unions the new table.
199
+ {{% include-md file="shared-content/postgres-considerations.md" %}}
299
200
300
201
## Examples
301
202
0 commit comments