fix: link-checker errors

Signed-off-by: Kyle Hounslow <kylhouns@amazon.com>

Author: kylehounslow

README.md

@@ -88,7 +88,7 @@ Recently we have been actively improving our query engine primarily for better c
 
 ## Documentation
 
-Please refer to the [SQL Language Reference Manual](./docs/user/index.rst), [Piped Processing Language (PPL) Reference Manual](./docs/user/ppl/index.rst), [OpenSearch SQL/PPL Engine Development Manual](./docs/dev/index.md) and [Technical Documentation](https://opensearch.org/docs/latest/search-plugins/sql/index/) for detailed information on installing and configuring plugin.
+Please refer to the [SQL Language Reference Manual](./docs/user/index.rst), [Piped Processing Language (PPL) Reference Manual](./docs/user/ppl/index.md), [OpenSearch SQL/PPL Engine Development Manual](./docs/dev/index.md) and [Technical Documentation](https://opensearch.org/docs/latest/search-plugins/sql/index/) for detailed information on installing and configuring plugin.
 
 ## Forum
 

docs/dev/intro-v3-engine.md

@@ -26,9 +26,9 @@ Find more details in [V3 Architecture](./intro-v3-architecture.md).
 
 In the initial release of the V3 engine (3.0.0), the main new features focus on enhancing the PPL language while maintaining maximum compatibility with V2 behavior.
 
-* **[Join](../user/ppl/cmd/join.rst) Command**
-* **[Lookup](../user/ppl/cmd/lookup.rst) Command**
-* **[Subquery](../user/ppl/cmd/subquery.rst) Command**
+* **[Join](../user/ppl/cmd/join.md) Command**
+* **[Lookup](../user/ppl/cmd/lookup.md) Command**
+* **[Subquery](../user/ppl/cmd/subquery.md) Command**
 
 V3 (Calcite integration) engine is enabled by default in 3.3.0.
 

docs/user/ppl/admin/connectors/s3glue_connector.md

@@ -8,7 +8,7 @@ This page covers s3Glue datasource configuration and also how to query and s3Glu
 
 * `EMRServerless Spark Execution Engine Config Setting`:  Since we execute s3Glue queries on top of spark execution engine, we require this configuration.  
 
-  More details: [ExecutionEngine Config](../../../interfaces/asyncqueryinterface.md#id2)
+  More details: [ExecutionEngine Config](../../../interfaces/asyncqueryinterface.rst#id2)
 * `S3`: This is where the data lies.  
 * `Glue` Metadata store: Glue takes care of table metadata.  
 * `Opensearch IndexStore`: Index for s3 data lies in opensearch and also acts as temporary buffer for query results.  
@@ -73,5 +73,5 @@ Sample Queries
 * Create Covering Index Query: `create index clientip_year on my_glue.default.http_logs (clientip, year) WITH (auto_refresh=true)`  
 * Create Skipping Index: `create skipping index on mys3.default.http_logs (status VALUE_SET)`  
 
-These queries would work only top of async queries. Documentation: [Async Query APIs](../../../interfaces/asyncqueryinterface.md)
+These queries would work only top of async queries. Documentation: [Async Query APIs](../../../interfaces/asyncqueryinterface.rst)
 Documentation for Index Queries: https://github.com/opensearch-project/opensearch-spark/blob/main/docs/index.md

docs/user/ppl/admin/connectors/security_lake_connector.md

@@ -7,7 +7,7 @@ Security Lake connector provides a way to query Security Lake tables.
 
 * `EMRServerless Spark Execution Engine Config Setting`:  Since we execute s3Glue queries on top of spark execution engine, we require this configuration.  
 
-  More details: [ExecutionEngine Config](../../../interfaces/asyncqueryinterface.md#id2)
+  More details: [ExecutionEngine Config](../../../interfaces/asyncqueryinterface.rst#id2)
 * `S3`: This is where the data lies.  
 * `Glue`: Metadata store: Glue takes care of table metadata.  
 * `Lake Formation`: AWS service that performs authorization on Security Lake tables  
@@ -59,5 +59,5 @@ Sample Queries
 * Select Query : `select * from mysl.amazon_security_lake_glue_db_eu_west_1.amazon_security_lake_table_eu_west_1_vpc_flow_2_0 limit 1`  
 * Create Covering Index Query: `create index srcip_time on mysl.amazon_security_lake_glue_db_eu_west_1.amazon_security_lake_table_eu_west_1_vpc_flow_2_0 (src_endpoint.ip, time) WITH (auto_refresh=true)`  
 
-These queries would work only top of async queries. Documentation: [Async Query APIs](../../../interfaces/asyncqueryinterface.md)
+These queries would work only top of async queries. Documentation: [Async Query APIs](../../../interfaces/asyncqueryinterface.rst)
 Documentation for Index Queries: https://github.com/opensearch-project/opensearch-spark/blob/main/docs/index.md

docs/user/ppl/functions/relevance.md

@@ -502,4 +502,4 @@ fetched rows / total rows = 2/2
 
 ### Limitations  
 
-The relevance functions are available to execute only in OpenSearch DSL but not in memory as of now, so the relevance search might fail for queries that are too complex to translate into DSL if the relevance function is following after a complex PPL query. To make your queries always work-able, it is recommended to place the relevance commands as close to the search command as possible, to ensure the relevance functions are eligible to push down. For example, a complex query like `search source = people | rename firstname as name | dedup account_number | fields name, account_number, balance, employer | where match(employer, 'Open Search') | stats count() by city` could fail because it is difficult to translate to DSL, but it would be better if we rewrite it to an equivalent query as `search source = people | where match(employer, 'Open Search') | rename firstname as name | dedup account_number | fields name, account_number, balance, employer | stats count() by city` by moving the where command with relevance function to the second command right after the search command, and the relevance would be optimized and executed smoothly in OpenSearch DSL. See [Optimization](../../optimization/optimization.md) to get more details about the query engine optimization.
+The relevance functions are available to execute only in OpenSearch DSL but not in memory as of now, so the relevance search might fail for queries that are too complex to translate into DSL if the relevance function is following after a complex PPL query. To make your queries always work-able, it is recommended to place the relevance commands as close to the search command as possible, to ensure the relevance functions are eligible to push down. For example, a complex query like `search source = people | rename firstname as name | dedup account_number | fields name, account_number, balance, employer | where match(employer, 'Open Search') | stats count() by city` could fail because it is difficult to translate to DSL, but it would be better if we rewrite it to an equivalent query as `search source = people | where match(employer, 'Open Search') | rename firstname as name | dedup account_number | fields name, account_number, balance, employer | stats count() by city` by moving the where command with relevance function to the second command right after the search command, and the relevance would be optimized and executed smoothly in OpenSearch DSL. See [Optimization](../../optimization/optimization.rst) to get more details about the query engine optimization.

docs/user/ppl/general/datatypes.md

@@ -58,7 +58,7 @@ Notes: Not all the PPL Type has correspond OpenSearch Type. e.g. data and time.
 Numeric values ranged from -2147483648 to +2147483647 are recognized as integer with type name `int`. For others outside the range, `bigint` integer will be the data type after parsed.
 ## Date and Time Data Types  
 
-The date and time data types are the types that represent temporal values and PPL plugin supports types including DATE, TIME, TIMESTAMP and INTERVAL. By default, the OpenSearch DSL uses date type as the only date and time related type, which has contained all information about an absolute time point. To integrate with PPL language, each of the types other than timestamp is holding part of temporal or timezone information, and the usage to explicitly clarify the date and time types is reflected in the datetime functions (see [Functions](functions.md) for details), where some functions might have restrictions in the input argument type.
+The date and time data types are the types that represent temporal values and PPL plugin supports types including DATE, TIME, TIMESTAMP and INTERVAL. By default, the OpenSearch DSL uses date type as the only date and time related type, which has contained all information about an absolute time point. To integrate with PPL language, each of the types other than timestamp is holding part of temporal or timezone information, and the usage to explicitly clarify the date and time types is reflected in the datetime functions (see [Functions](../functions/datetime.md) for details), where some functions might have restrictions in the input argument type.
 ### Date  
 
 Date represents the calendar date regardless of the time zone. A given date value represents a 24-hour period, or say a day, but this period varies in different timezones and might have flexible hours during Daylight Savings Time programs. Besides, the date type does not contain time information as well. The supported range is '1000-01-01' to '9999-12-31'.
@@ -91,7 +91,7 @@ Interval data type represents a temporal duration or a period. The syntax is as
 | --- | --- |
 | Interval | INTERVAL expr unit |
 
-The expr is any expression that can be iterated to a quantity value eventually, see [Expressions](expressions.md) for details. The unit represents the unit for interpreting the quantity, including MICROSECOND, SECOND, MINUTE, HOUR, DAY, WEEK, MONTH, QUARTER and YEAR.The INTERVAL keyword and the unit specifier are not case sensitive. Note that there are two classes of intervals. Year-week intervals can store years, quarters, months and weeks. Day-time intervals can store days, hours, minutes, seconds and microseconds. Year-week intervals are comparable only with another year-week intervals. These two types of intervals can only comparable with the same type of themselves.
+The expr is any expression that can be iterated to a quantity value eventually, see [Expressions](../functions/expressions.md) for details. The unit represents the unit for interpreting the quantity, including MICROSECOND, SECOND, MINUTE, HOUR, DAY, WEEK, MONTH, QUARTER and YEAR.The INTERVAL keyword and the unit specifier are not case sensitive. Note that there are two classes of intervals. Year-week intervals can store years, quarters, months and weeks. Day-time intervals can store days, hours, minutes, seconds and microseconds. Year-week intervals are comparable only with another year-week intervals. These two types of intervals can only comparable with the same type of themselves.
 ### Conversion between date and time types  
 
 Basically the date and time types except interval can be converted to each other, but might suffer some alteration of the value or some information loss, for example extracting the time value from a timestamp value, or convert a date value to a timestamp value and so forth. Here lists the summary of the conversion rules that PPL plugin supports for each of the types: