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

Commit83412c7

Browse files
committed
Clarify type resolution behavior for domain types.
The user documentation was vague and not entirely accurate about howwe treat domain inputs for ambiguous operators/functions. Clarifythat, and add an example and some commentary. Per a recent questionfrom Adam Mackler.It's acted like this ever since we added domains, so back-patchto all supported branches.
1 parentbbe826f commit83412c7

File tree

1 file changed

+88
-13
lines changed

1 file changed

+88
-13
lines changed

‎doc/src/sgml/typeconv.sgml

Lines changed: 88 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -185,7 +185,9 @@ That is, if a query is well-formed and the types already match, then the query s
185185
without spending extra time in the parser and without introducing unnecessary implicit conversion
186186
calls in the query.
187187
</para>
188+
</listitem>
188189

190+
<listitem>
189191
<para>
190192
Additionally, if a query usually requires an implicit conversion for a function, and
191193
if then the user defines a new function with the correct argument types, the parser
@@ -209,15 +211,15 @@ should use this new function and no longer do implicit conversion to use the old
209211
The specific operator that is referenced by an operator expression
210212
is determined using the following procedure.
211213
Note that this procedure is indirectly affected
212-
by the precedence of theinvolvedoperators, since that will determine
214+
by the precedence of the operators involved, since that will determine
213215
which sub-expressions are taken to be the inputs of which operators.
214216
See <xref linkend="sql-precedence"> for more information.
215217
</para>
216218

217219
<procedure>
218220
<title>Operator Type Resolution</title>
219221

220-
<step performance="required">
222+
<stepid="op-resol-select"performance="required">
221223
<para>
222224
Select the operators to be considered from the
223225
<classname>pg_operator</classname> system catalog. If a non-schema-qualified
@@ -240,26 +242,33 @@ search path position.
240242
</substeps>
241243
</step>
242244

243-
<step performance="required">
245+
<stepid="op-resol-exact-match"performance="required">
244246
<para>
245247
Check for an operator accepting exactly the input argument types.
246248
If one exists (there can be only one exact match in the set of
247249
operators considered), use it.
248250
</para>
249251

250252
<substeps>
251-
<step performance="optional">
253+
<stepid="op-resol-exact-unknown"performance="optional">
252254
<para>
253255
If one argument of a binary operator invocation is of the <type>unknown</type> type,
254256
then assume it is the same type as the other argument for this check.
255257
Invocations involving two <type>unknown</type> inputs, or a unary operator
256258
with an <type>unknown</type> input, will never find a match at this step.
257259
</para>
258260
</step>
261+
<step id="op-resol-exact-domain" performance="optional">
262+
<para>
263+
If one argument of a binary operator invocation is of the <type>unknown</type>
264+
type and the other is of a domain type, next check to see if there is an
265+
operator accepting exactly the domain's base type on both sides; if so, use it.
266+
</para>
267+
</step>
259268
</substeps>
260269
</step>
261270

262-
<step performance="required">
271+
<stepid="op-resol-best-match"performance="required">
263272
<para>
264273
Look for the best match.
265274
</para>
@@ -275,9 +284,15 @@ candidate remains, use it; else continue to the next step.
275284
</step>
276285
<step performance="required">
277286
<para>
287+
If any input argument is of a domain type, treat it as being of the
288+
domain's base type for all subsequent steps. This ensures that domains
289+
act like their base types for purposes of ambiguous-operator resolution.
290+
</para>
291+
</step>
292+
<step performance="required">
293+
<para>
278294
Run through all candidates and keep those with the most exact matches
279-
on input types. (Domains are considered the same as their base type
280-
for this purpose.) Keep all candidates if none have exact matches.
295+
on input types. Keep all candidates if none have exact matches.
281296
If only one candidate remains, use it; else continue to the next step.
282297
</para>
283298
</step>
@@ -376,7 +391,7 @@ be interpreted as type <type>text</type>.
376391
</para>
377392

378393
<para>
379-
Here is a concatenationon unspecified types:
394+
Here is a concatenationof two values of unspecified types:
380395
<screen>
381396
SELECT 'abc' || 'def' AS "unspecified";
382397

@@ -394,7 +409,7 @@ and finds that there are candidates accepting both string-category and
394409
bit-string-category inputs. Since string category is preferred when available,
395410
that category is selected, and then the
396411
preferred type for strings, <type>text</type>, is used as the specific
397-
type to resolve the unknown literals as.
412+
type to resolve the unknown-type literals as.
398413
</para>
399414
</example>
400415

@@ -450,6 +465,45 @@ SELECT ~ CAST('20' AS int8) AS "negation";
450465
</para>
451466
</example>
452467

468+
<example>
469+
<title>Custom Operator on a Domain Type</title>
470+
471+
<para>
472+
Users sometimes try to declare operators applying just to a domain type.
473+
This is possible but is not nearly as useful as it might seem, because the
474+
operator resolution rules are designed to select operators applying to the
475+
domain's base type. As an example consider
476+
<screen>
477+
CREATE DOMAIN mytext AS text CHECK(...);
478+
CREATE FUNCTION mytext_eq_text (mytext, text) RETURNS boolean AS ...;
479+
CREATE OPERATOR = (procedure=mytext_eq_text, leftarg=mytext, rightarg=text);
480+
CREATE TABLE mytable (val mytext);
481+
482+
SELECT * FROM mytable WHERE val = 'foo';
483+
</screen>
484+
This query will not use the custom operator. The parser will first see if
485+
there is a <type>mytext</> <literal>=</> <type>mytext</> operator
486+
(<xref linkend="op-resol-exact-unknown">), which there is not;
487+
then it will consider the domain's base type <type>text</>, and see if
488+
there is a <type>text</> <literal>=</> <type>text</> operator
489+
(<xref linkend="op-resol-exact-domain">), which there is;
490+
so it resolves the <type>unknown</>-type literal as <type>text</> and
491+
uses the <type>text</> <literal>=</> <type>text</> operator.
492+
The only way to get the custom operator to be used is to explicitly cast
493+
the literal:
494+
<screen>
495+
SELECT * FROM mytable WHERE val = text 'foo';
496+
</screen>
497+
so that the <type>mytext</> <literal>=</> <type>text</> operator is found
498+
immediately according to the exact-match rule. If the best-match rules
499+
are reached, they actively discriminate against operators on domain types.
500+
If they did not, such an operator would create too many ambiguous-operator
501+
failures, because the casting rules always consider a domain as castable
502+
to or from its base type, and so the domain operator would be considered
503+
usable in all the same cases as a similarly-named operator on the base type.
504+
</para>
505+
</example>
506+
453507
</sect1>
454508

455509
<sect1 id="typeconv-func">
@@ -565,9 +619,15 @@ candidate remains, use it; else continue to the next step.
565619
</step>
566620
<step performance="required">
567621
<para>
622+
If any input argument is of a domain type, treat it as being of the
623+
domain's base type for all subsequent steps. This ensures that domains
624+
act like their base types for purposes of ambiguous-function resolution.
625+
</para>
626+
</step>
627+
<step performance="required">
628+
<para>
568629
Run through all candidates and keep those with the most exact matches
569-
on input types. (Domains are considered the same as their base type
570-
for this purpose.) Keep all candidates if none have exact matches.
630+
on input types. Keep all candidates if none have exact matches.
571631
If only one candidate remains, use it; else continue to the next step.
572632
</para>
573633
</step>
@@ -858,8 +918,23 @@ and Related Constructs</title>
858918
<step performance="required">
859919
<para>
860920
If all inputs are of the same type, and it is not <type>unknown</type>,
861-
resolve as that type. Otherwise, replace any domain types in the list with
862-
their underlying base types.
921+
resolve as that type.
922+
</para>
923+
</step>
924+
925+
<step performance="required">
926+
<para>
927+
If any input is of a domain type, treat it as being of the
928+
domain's base type for all subsequent steps.
929+
<footnote>
930+
<para>
931+
Somewhat like the treatment of domain inputs for operators and
932+
functions, this behavior allows a domain type to be preserved through
933+
a <literal>UNION</> or similar construct, so long as the user is
934+
careful to ensure that all inputs are implicitly or explicitly of that
935+
exact type. Otherwise the domain's base type will be preferred.
936+
</para>
937+
</footnote>
863938
</para>
864939
</step>
865940

0 commit comments

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