Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commitb55f2b6

Browse files
committed
Adjust pg_dump's priority ordering for casts.
When a stored expression depends on a user-defined cast, the backendrecords the dependency as being on the cast's implementation function--- or indeed, if there's no cast function involved but justRelabelType or CoerceViaIO, no dependency is recorded at all. Thisis problematic for pg_dump, which is at risk of dumping things in thewrong order leading to restore failures. Given the lack of previousreports, the risk isn't that high, but it can be demonstrated if thecast is used in some view whose rowtype is then used as an input orresult type for some other function. (That results in the viewgetting hoisted into the functions portion of the dump, ahead ofthe cast.)A logically bulletproof fix for this would require including thecast's OID in the parsed form of the expression, whence it could beextracted by dependency.c, and then the stored dependency would forcepg_dump to do the right thing. Such a change would be fairly invasive,and certainly not back-patchable. Moreover, since we'd prefer thatan expression using cast syntax be equal() to one doing the samething by explicit function call, the cast OID field would have tohave special ignored-by-comparisons semantics, making things messy.So, let's instead fix this by a very simple hack in pg_dump: changethe object-type priority order so that casts are initially sortedbefore functions, immediately after types. This fixes the problemin a fairly direct way for casts that have no implementation function.For those that do, the implementation function will be hoisted to justbefore the cast by the dependency sorting step, so that we still havea valid dump order. (I'm not sure that this provides a full guaranteeof no problems; but since it's been like this for many years withoutany previous reports, this is probably enough to fix it in practice.)Per report from Дмитрий Иванов.Back-patch to all supported branches.Discussion:https://postgr.es/m/CAPL5KHoGa3uvyKp6z6m48LwCnTsK+LRQ_mcA4uKGfqAVSEjV_A@mail.gmail.com
1 parentdb3a660 commitb55f2b6

File tree

1 file changed

+10
-1
lines changed

1 file changed

+10
-1
lines changed

‎src/bin/pg_dump/pg_dump_sort.c

Lines changed: 10 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -34,6 +34,15 @@
3434
* restore state). If you think to change this, see also the RestorePass
3535
* mechanism in pg_backup_archiver.c.
3636
*
37+
* On the other hand, casts are intentionally sorted earlier than you might
38+
* expect; logically they should come after functions, since they usually
39+
* depend on those. This works around the backend's habit of recording
40+
* views that use casts as dependent on the cast's underlying function.
41+
* We initially sort casts first, and then any functions used by casts
42+
* will be hoisted above the casts, and in turn views that those functions
43+
* depend on will be hoisted above the functions. But views not used that
44+
* way won't be hoisted.
45+
*
3746
* NOTE: object-type priorities must match the section assignments made in
3847
* pg_dump.c; that is, PRE_DATA objects must sort before DO_PRE_DATA_BOUNDARY,
3948
* POST_DATA objects must sort after DO_POST_DATA_BOUNDARY, and DATA objects
@@ -49,12 +58,12 @@ enum dbObjectTypePriorities
4958
PRIO_TRANSFORM,
5059
PRIO_EXTENSION,
5160
PRIO_TYPE,/* used for DO_TYPE and DO_SHELL_TYPE */
61+
PRIO_CAST,
5262
PRIO_FUNC,
5363
PRIO_AGG,
5464
PRIO_ACCESS_METHOD,
5565
PRIO_OPERATOR,
5666
PRIO_OPFAMILY,/* used for DO_OPFAMILY and DO_OPCLASS */
57-
PRIO_CAST,
5867
PRIO_CONVERSION,
5968
PRIO_TSPARSER,
6069
PRIO_TSTEMPLATE,

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp