…gParquetColumns

Append nulls for missing values in Parquet.

Criteo specific travis yaml updates

# This is the 1st commit message:

# This is a combination of 8 commits.
# This is the 1st commit message:

# This is a combination of 6 commits.
# This is the 1st commit message:

# This is a combination of 3 commits.
# This is the 1st commit message:

# This is a combination of 6 commits.
# This is the 1st commit message:

# This is a combination of 3 commits.
# This is the 1st commit message:

# This is a combination of 2 commits.
# This is the 1st commit message:

# This is a combination of 2 commits.
# This is the 1st commit message:

# This is a combination of 4 commits.
# This is the 1st commit message:

# This is a combination of 2 commits.
# This is the 1st commit message:

# This is a combination of 3 commits.
# This is the 1st commit message:

# This is a combination of 4 commits.
# This is the 1st commit message:

 WIP: Ranger integration with presto. Please change local file path

# This is the commit message prestodb#2:

Making information schema skippable

# This is the commit message prestodb#3:

minor improvements

# This is the commit message prestodb#4:

Fix truncated print for ProjectionNode in PlanPrinter

# This is the commit message prestodb#2:

Cleanup all temporary files when writing sorted Hive tables

# This is the commit message prestodb#3:

Prevent nulls fraction to be negative in subtractColumnStats

# This is the commit message prestodb#2:

Better estimate NDVs and range in subtractColumnStats

When there is too little rows per distinct values to
be substracted, then both original range and NDVs
should be preserved.

# This is the commit message prestodb#2:

Mark subtractColumnStats as @deprecated as it semantics is undefined

# This is the commit message prestodb#3:

Dispose resources in WorkProcessorUtils when they are no longer needed

# This is the commit message prestodb#4:

Add WorkProcessor#transformProcessor method

This methods allows to write more streamlined
transformations of the processor itself, e.g:

processor.transformProcessor(WorkProcessorUtils::flatten)

# This is the commit message prestodb#2:

Fix error message in QuerySessionSupplier

# This is the commit message prestodb#2:

Rename singleExpression to standaloneExpression

This better reflects the intent of the parsing rule.

# This is the commit message prestodb#2:

Improve parsing error message

The name appears as the prefix of some errors. E.g.,

    xxxxx is too large (stack overflow while parsing)

"path specification" reads better than "pathSpec"

# This is the commit message prestodb#3:

Log raised during error handling

It was logging the parsing exception, not the exception that could
occur while handling the parsing error due to a bug in the implementation.

# This is the commit message prestodb#2:

Tighten assertion for parsing failure in TestSqlEnvironmentConfig

# This is the commit message prestodb#3:

Implement recursion-free ATN simulator

The new implementation tracks all the possible states the ATN can be
in in a single queue instead of recursing when processing sub-rules.

This vastly simplifies the code, makes it easier to reason about and
debug. It also fixes a latent bug where some contexts were not being
visited, which missed some candidate tokens.

# This is the commit message prestodb#4:

Raise requried Java version to 8u151

Some test cases failed due to JDK MethodHandle bug in 8u92.
These tests passed in 8u151.

# This is the commit message prestodb#5:

Track origin column for fields

This is needed to ensure we only check column access privileges for
origin columns.

# This is the commit message prestodb#6:

Don't check column access for aliases

Fixes queries that have column aliases defined in the query like
`SELECT col1 AS my_alias FROM table`.  Previously, we checked if a
user had permission to access "col1" and "my_alias". Now we only
 check "col1".

# This is the commit message prestodb#2:

Add wrapped Boolean benchmarks

Benchmark                                         Mode  Cnt     Score    Error   Units
BenchmarkBoxedBoolean.booleanEquals              thrpt   30  4596.863 ± 26.817  ops/ms
BenchmarkBoxedBoolean.booleanEqualsNotNull       thrpt   30  4484.421 ± 43.358  ops/ms
BenchmarkBoxedBoolean.identity                   thrpt   30  4610.811 ± 85.104  ops/ms
BenchmarkBoxedBoolean.object                     thrpt   30  4558.072 ± 68.325  ops/ms
BenchmarkBoxedBoolean.primitive                  thrpt   30  4450.140 ± 52.258  ops/ms
BenchmarkBoxedBoolean.unboxing                   thrpt   30  4506.205 ± 26.116  ops/ms

# This is the commit message prestodb#3:

Implement equality comparisons projection benchmark

Bechmark creates an expression with 100 comparisions concatenated with
OR and executes them on a single 1MB page with 10 BIGINT channels.

Before change:

Benchmark                                  Mode  Cnt     Score    Error  Units
BenchmarkEqualsOperator.processPage	   avgt   15  5164.793 ± 29.110  us/op

After change:

Benchmark                                  Mode  Cnt     Score    Error  Units
BenchmarkEqualsOperator.processPage	   avgt   15  5142.010 ± 59.681  us/op

# This is the commit message prestodb#2:

Implement nullable EQUAL and NOT_EQUAL for ARRAY type

# This is the commit message prestodb#3:

Change equals semantincs for null in MAP

Make it comptible with current ARRAY equals semantics

If the key sets are different - return false.
If the key sets are the same - compare the values as if they
were arrays sorted by the keys.

# This is the commit message prestodb#4:

Implement nullable EQUAL and NOT_EQUAL for ROW type

# This is the commit message prestodb#5:

Support IN predicate for complex type values with nulls

# This is the commit message prestodb#6:

Allow alternate implementations of HiveMetadata

Extracting an interface allows implementations that use delegation
rather than subclasses.

# This is the commit message prestodb#2:

Fix handling of thread interruption in JDBC driver

When using sockets created using SocketChannel, OkHttp handles thread
interruption differently and does not restore the interrupt status.

# This is the commit message prestodb#3:

Add per table column_ranges system table in Raptor

# This is the commit message prestodb#4:

Fix Hive smoke test when running in parallel

Use a different table name for testCreateEmptyBucketedPartition
and testInsertPartitionedBucketedTable to avoid test failures
when running in parallel.

# This is the commit message prestodb#5:

Separate EXCEEDED_MEMORY_LIMIT error into local and global

# This is the commit message prestodb#6:

Fix test failures due to ExceededMemoryLimitException message

# This is the commit message prestodb#7:

Fix more test failures due to ExceededMemoryLimitException message

A few tests failures are not fixed by
47355c8

# This is the commit message prestodb#8:

Replace usage of deprecated TreeTraverser

# This is the commit message prestodb#2:

Add missing column to verifier SQL documentation

debug print

 This is the commit message prestodb#2:

Update commons-dbcp2 version to fix common vulnerabilities and exposures

Update commons-dbcp2 version to fix common vulnerabilities and exposures

# This is the 1st commit message:

Add session properties for scale writer query configs

# This is the commit message prestodb#2:

Add session properties to coordinator

# This is the 1st commit message:

[native] Add a test group for async data cache e2e tests.

# This is the commit message prestodb#2:

[native] Advance velox.

# This is the commit message prestodb#3:

Fix error when describing a nonexistent table

# This is the commit message prestodb#4:

[native] test modification.

# This is the commit message prestodb#5:

Changes to enable ssl/tls in hms
Co-authored-by: Arin Mathew <arin.mathew1@ibm.com>

Changes to move ssl related properties to seperate class

# This is the commit message prestodb#6:

[native] Add tests for UUID type

# This is the commit message prestodb#7:

Reintroduced json_extract to generate canonicalized output (prestodb#24879)

## Description
The original pull request
[prestodb#24614](prestodb#24614) incorrectly
compares canonicalizedJsonExtract and legacyJsonCast in the equals
function of an object. This issue can be seen in the code
[here](https://github.com/prestodb/presto/pull/24614/files#diff-e921c5d186f9d5daa836bc7330f52caf8c1b84d19cf42288d5a8a7c9a6d2a5d5R156).

As a result, whenever a SQL function requires caching, the cache is
never hit, leading to the creation of new SQL function objects
repeatedly. This behavior eventually causes an OOM error in the JVM
metaspace. and eventually this error led to UER SEV.

After the problematic comparison was updated and tested through shadow
cluster by @rschlussel , we are confident that the issue has been
resolved in this PR. Therefore, we plan to bring back the json
canonicalized extract


## Motivation and Context
Reintroduced json_extract to generate canonicalized output

## Impact
<!---Describe any public API or user-facing feature change or any
performance impact-->
low impact 

## Test Plan
<!---Please fill in how you tested your change-->
N/A

## Contributor checklist

- [x] Please make sure your submission complies with our [contributing
guide](https://github.com/prestodb/presto/blob/master/CONTRIBUTING.md),
in particular [code
style](https://github.com/prestodb/presto/blob/master/CONTRIBUTING.md#code-style)
and [commit
standards](https://github.com/prestodb/presto/blob/master/CONTRIBUTING.md#commit-standards).
- [x] PR description addresses the issue accurately and concisely. If
the change is non-trivial, a GitHub Issue is referenced.
- [x] Documented new properties (with its default value), SQL syntax,
functions, or other functionality.
- [x] If release notes are required, they follow the [release notes
guidelines](https://github.com/prestodb/presto/wiki/Release-Notes-Guidelines).
- [x] Adequate tests were added if applicable.
- [x] CI passed.

## Release Notes
Please follow [release notes
guidelines](https://github.com/prestodb/presto/wiki/Release-Notes-Guidelines)
and fill in the release notes below.

```
== NO RELEASE NOTE ==
```
# This is the commit message prestodb#8:

Reuse JoinType in IndexJoinNode

Reuse JoinType instead of creating IndexJoinNode's own. JoinType is
already part of Prestissimo protocol. Adding IndexJoinNode with another
JoinType would cause naming conflict.

# This is the commit message prestodb#9:

Add jaro-winkler implementation, documentation and tests

# This is the commit message prestodb#10:

Add documentation for Iceberg support in PrestoCPP

# This is the commit message prestodb#11:

Add memory pool debug regex

# This is the commit message prestodb#12:

doc on hive csv limitations

# This is the commit message prestodb#13:

Add support for S3 WebIdentity authentication

# This is the commit message prestodb#14:

use com.facebook.airlift:security in presto-hive-metastore

# This is the commit message prestodb#15:

[native] Advance Velox

# This is the commit message prestodb#16:

[native] Add protocol for index lookup join plan

# This is the commit message prestodb#17:

[native] Add sidecar and sidecar plugin documentation

pick changes from [pos][native]3.4 upgrade changes prestodb#2

code compatible for spark2 and spark3

make code compatible for spark2.4 and spark3.4

keep classloader

add presto-spark-classloader-spark into main pom dep

create module presto-spark-classloader-common

Trigger build

set relativePath of parent pom

set relativePath for presto-spark-classloader-common

fix deserialize of PrestoSparkShuffleSerializer

refactor presto-spark-classloader* modules

update classloader modules

fix parent relativePath

relative path of parent

update classloader-spark pom

update to 0.295

Trigger build

remove enforceBytecodeVersion

use jakarta dep and errorprone

remove duplicate dep jakarta.annotation-api

pick changes from [pos][native]3.4 upgrade changes prestodb#2

code compatible for spark2 and spark3

make code compatible for spark2.4 and spark3.4

keep classloader

add presto-spark-classloader-spark into main pom dep

create module presto-spark-classloader-common

Trigger build

set relativePath of parent pom

set relativePath for presto-spark-classloader-common

fix deserialize of PrestoSparkShuffleSerializer

refactor presto-spark-classloader* modules

update classloader modules

fix parent relativePath

relative path of parent

update classloader-spark pom

update to 0.295

Trigger build

remove enforceBytecodeVersion

use jakarta dep and errorprone

remove duplicate dep jakarta.annotation-api

update presto-spark-classloader-interface dep

add presto-spark-base and spark-core

## Summary:
This reverts the following PR
GitHub Pull Request: #27199
GitHub Author: Deepak Mehra mehradeeeepak@gmail.com
Meta internal revision:D96106074

Fully reverts the HAVING alias expansion feature, which threw
7 failed queries (2 different errors) on meta internal test suites. I
have verified that these errors are all caused by this change by
attempting to fix them and testing that the revert clears the errors.

## Errors:
1. java.sql.SQLException: Query failed (#20260316_083518_04833_pwriw):
type of variable 'expr_189' is expected 2. to be varchar(25), but the
actual type is varchar
java.sql.SQLException: Query failed (#20260316_083713_05663_pwriw):
Cannot nest aggregations inside aggregation 'sum':
["sum"(CTX_pe_revenue)]

## Root cause:
The PR added SELECT alias resolution in HAVING by rewriting
the HAVING predicate with OrderByExpressionRewriter. This caused two
bugs:
1. Type mismatches (5 failures): (AI reasoning) When a column name
matches a SELECT alias
(e.g., SELECT CASE...END AS category), the rewriter expands the column
reference in HAVING to the full CASE expression, changing its type from
varchar(25) to unbounded varchar. QueryPlanner.filter() uses the
rewritten expression via analysis.getHaving(), creating plan nodes with
mismatched types that TypeValidator rejects.
2. Nested aggregation (1 failure): (confirmed) When a SELECT alias
references an
aggregation and HAVING uses that alias inside another aggregation
(e.g., HAVING sum(total) where total = sum(x)), expansion creates
invalid nested aggregations sum(sum(x))
3. bigint vs double (1 failure): Same mechanism as issue 1 but with
numeric
type coercion differences.

## Fix:
I tried to fix these issues, but only managed to clear the error for #2.
Reverting the change due to these errors.
According to AI:
The HAVING alias resolution feature needs a different implementation
that
doesn't change expression types in the plan — likely by resolving
aliases
during planning rather than during analysis.

## Reproduction:
I can't share the reproducing queries since they reference meta internal
data, but these should give you an idea of how to reproduce the issues

Bug 1: Type mismatch (varchar(25) vs varchar)

```
  -- The SELECT aliases `category` to a CASE expression returning varchar strings.
  -- HAVING references `category` which the rewriter expands to the CASE expression,
  -- changing its type from the subquery's varchar(25) to unbounded varchar.
  -- Triggers: "type of variable 'expr_N' is expected to be varchar(25), but the actual type is varchar"

  WITH data AS (
      SELECT
          CAST('cpu' AS varchar(25)) AS category,
          true AS is_cpu,
          100.0 AS value
      UNION ALL
      SELECT CAST('gpu' AS varchar(25)), false, 200.0
  )
  SELECT
      (CASE
          WHEN COALESCE(category, CAST(is_cpu AS varchar)) IS NULL THEN 'total'
          WHEN is_cpu THEN 'cpu_total'
          ELSE category
      END) category,
      sum(value) AS total_value
  FROM data
  GROUP BY GROUPING SETS ((), (category), (is_cpu))
  HAVING (CASE
      WHEN COALESCE(category, CAST(is_cpu AS varchar)) IS NULL THEN 'total'
      WHEN is_cpu THEN 'cpu_total'
      ELSE category
  END) IS NOT NULL
```

  Bug 2: Nested aggregation (SYNTAX_ERROR)

```
  -- SELECT defines `total` as sum(revenue). HAVING uses sum(total).
  -- The rewriter expands `total` to `sum(revenue)`, creating sum(sum(revenue)).
  -- Triggers: "Cannot nest aggregations inside aggregation 'sum': ["sum"(revenue)]"

  SELECT
      region,
      sum(revenue) AS total
  FROM (
      VALUES ('us', 100), ('eu', 200), ('us', 150), ('eu', 50)
  ) AS t(region, revenue)
  GROUP BY region
  HAVING sum(total) > 100
```

Differential Revision: D97181706

## Summary by Sourcery

Revert support for resolving SELECT output aliases in HAVING clauses and
restore previous validation behavior.

Enhancements:
- Simplify OrderByExpressionRewriter by removing clause-specific error
context now that it is only used for ORDER BY.

Tests:
- Update analyzer tests to again treat alias references in HAVING as
invalid and remove related positive and error-coverage cases.


## Release Notes
Please follow [release notes
guidelines](https://github.com/prestodb/presto/wiki/Release-Notes-Guidelines)
and fill in the release notes below.

```
== RELEASE NOTES ==

General Changes
* Fix 2 bugs caused by Select Alias references in Having clause

Co-authored-by: mehradeeeepak@gmail.com <mehradeeeepak@gmail.com>

## Summary:
This reverts the following PR
GitHub Pull Request: #27199
GitHub Author: Deepak Mehra mehradeeeepak@gmail.com
Meta internal revision:D96106074

Fully reverts the HAVING alias expansion feature, which threw
7 failed queries (2 different errors) on meta internal test suites. I
have verified that these errors are all caused by this change by
attempting to fix them and testing that the revert clears the errors.

## Errors:
1. java.sql.SQLException: Query failed (#20260316_083518_04833_pwriw):
type of variable 'expr_189' is expected 2. to be varchar(25), but the
actual type is varchar
java.sql.SQLException: Query failed (#20260316_083713_05663_pwriw):
Cannot nest aggregations inside aggregation 'sum':
["sum"(CTX_pe_revenue)]

## Root cause:
The PR added SELECT alias resolution in HAVING by rewriting
the HAVING predicate with OrderByExpressionRewriter. This caused two
bugs:
1. Type mismatches (5 failures): (AI reasoning) When a column name
matches a SELECT alias
(e.g., SELECT CASE...END AS category), the rewriter expands the column
reference in HAVING to the full CASE expression, changing its type from
varchar(25) to unbounded varchar. QueryPlanner.filter() uses the
rewritten expression via analysis.getHaving(), creating plan nodes with
mismatched types that TypeValidator rejects.
2. Nested aggregation (1 failure): (confirmed) When a SELECT alias
references an
aggregation and HAVING uses that alias inside another aggregation
(e.g., HAVING sum(total) where total = sum(x)), expansion creates
invalid nested aggregations sum(sum(x))
3. bigint vs double (1 failure): Same mechanism as issue 1 but with
numeric
type coercion differences.

## Fix:
I tried to fix these issues, but only managed to clear the error for #2.
Reverting the change due to these errors.
According to AI:
The HAVING alias resolution feature needs a different implementation
that
doesn't change expression types in the plan — likely by resolving
aliases
during planning rather than during analysis.

## Reproduction:
I can't share the reproducing queries since they reference meta internal
data, but these should give you an idea of how to reproduce the issues

Bug 1: Type mismatch (varchar(25) vs varchar)

```
  -- The SELECT aliases `category` to a CASE expression returning varchar strings.
  -- HAVING references `category` which the rewriter expands to the CASE expression,
  -- changing its type from the subquery's varchar(25) to unbounded varchar.
  -- Triggers: "type of variable 'expr_N' is expected to be varchar(25), but the actual type is varchar"

  WITH data AS (
      SELECT
          CAST('cpu' AS varchar(25)) AS category,
          true AS is_cpu,
          100.0 AS value
      UNION ALL
      SELECT CAST('gpu' AS varchar(25)), false, 200.0
  )
  SELECT
      (CASE
          WHEN COALESCE(category, CAST(is_cpu AS varchar)) IS NULL THEN 'total'
          WHEN is_cpu THEN 'cpu_total'
          ELSE category
      END) category,
      sum(value) AS total_value
  FROM data
  GROUP BY GROUPING SETS ((), (category), (is_cpu))
  HAVING (CASE
      WHEN COALESCE(category, CAST(is_cpu AS varchar)) IS NULL THEN 'total'
      WHEN is_cpu THEN 'cpu_total'
      ELSE category
  END) IS NOT NULL
```

  Bug 2: Nested aggregation (SYNTAX_ERROR)

```
  -- SELECT defines `total` as sum(revenue). HAVING uses sum(total).
  -- The rewriter expands `total` to `sum(revenue)`, creating sum(sum(revenue)).
  -- Triggers: "Cannot nest aggregations inside aggregation 'sum': ["sum"(revenue)]"

  SELECT
      region,
      sum(revenue) AS total
  FROM (
      VALUES ('us', 100), ('eu', 200), ('us', 150), ('eu', 50)
  ) AS t(region, revenue)
  GROUP BY region
  HAVING sum(total) > 100
```

Differential Revision: D97181706

## Summary by Sourcery

Revert support for resolving SELECT output aliases in HAVING clauses and
restore previous validation behavior.

Enhancements:
- Simplify OrderByExpressionRewriter by removing clause-specific error
context now that it is only used for ORDER BY.

Tests:
- Update analyzer tests to again treat alias references in HAVING as
invalid and remove related positive and error-coverage cases.


## Release Notes
Please follow [release notes
guidelines](https://github.com/prestodb/presto/wiki/Release-Notes-Guidelines)
and fill in the release notes below.

```
== RELEASE NOTES ==

General Changes
* Fix 2 bugs caused by Select Alias references in Having clause

Co-authored-by: mehradeeeepak@gmail.com <mehradeeeepak@gmail.com>

)

## Summary:
This reverts the following PR
GitHub Pull Request: prestodb#27199
GitHub Author: Deepak Mehra mehradeeeepak@gmail.com
Meta internal revision:D96106074

Fully reverts the HAVING alias expansion feature, which threw
7 failed queries (2 different errors) on meta internal test suites. I
have verified that these errors are all caused by this change by
attempting to fix them and testing that the revert clears the errors.

## Errors:
1. java.sql.SQLException: Query failed (#20260316_083518_04833_pwriw):
type of variable 'expr_189' is expected 2. to be varchar(25), but the
actual type is varchar
java.sql.SQLException: Query failed (#20260316_083713_05663_pwriw):
Cannot nest aggregations inside aggregation 'sum':
["sum"(CTX_pe_revenue)]

## Root cause:
The PR added SELECT alias resolution in HAVING by rewriting
the HAVING predicate with OrderByExpressionRewriter. This caused two
bugs:
1. Type mismatches (5 failures): (AI reasoning) When a column name
matches a SELECT alias
(e.g., SELECT CASE...END AS category), the rewriter expands the column
reference in HAVING to the full CASE expression, changing its type from
varchar(25) to unbounded varchar. QueryPlanner.filter() uses the
rewritten expression via analysis.getHaving(), creating plan nodes with
mismatched types that TypeValidator rejects.
2. Nested aggregation (1 failure): (confirmed) When a SELECT alias
references an
aggregation and HAVING uses that alias inside another aggregation
(e.g., HAVING sum(total) where total = sum(x)), expansion creates
invalid nested aggregations sum(sum(x))
3. bigint vs double (1 failure): Same mechanism as issue 1 but with
numeric
type coercion differences.

## Fix:
I tried to fix these issues, but only managed to clear the error for prestodb#2.
Reverting the change due to these errors.
According to AI:
The HAVING alias resolution feature needs a different implementation
that
doesn't change expression types in the plan — likely by resolving
aliases
during planning rather than during analysis.

## Reproduction:
I can't share the reproducing queries since they reference meta internal
data, but these should give you an idea of how to reproduce the issues

Bug 1: Type mismatch (varchar(25) vs varchar)

```
  -- The SELECT aliases `category` to a CASE expression returning varchar strings.
  -- HAVING references `category` which the rewriter expands to the CASE expression,
  -- changing its type from the subquery's varchar(25) to unbounded varchar.
  -- Triggers: "type of variable 'expr_N' is expected to be varchar(25), but the actual type is varchar"

  WITH data AS (
      SELECT
          CAST('cpu' AS varchar(25)) AS category,
          true AS is_cpu,
          100.0 AS value
      UNION ALL
      SELECT CAST('gpu' AS varchar(25)), false, 200.0
  )
  SELECT
      (CASE
          WHEN COALESCE(category, CAST(is_cpu AS varchar)) IS NULL THEN 'total'
          WHEN is_cpu THEN 'cpu_total'
          ELSE category
      END) category,
      sum(value) AS total_value
  FROM data
  GROUP BY GROUPING SETS ((), (category), (is_cpu))
  HAVING (CASE
      WHEN COALESCE(category, CAST(is_cpu AS varchar)) IS NULL THEN 'total'
      WHEN is_cpu THEN 'cpu_total'
      ELSE category
  END) IS NOT NULL
```

  Bug 2: Nested aggregation (SYNTAX_ERROR)

```
  -- SELECT defines `total` as sum(revenue). HAVING uses sum(total).
  -- The rewriter expands `total` to `sum(revenue)`, creating sum(sum(revenue)).
  -- Triggers: "Cannot nest aggregations inside aggregation 'sum': ["sum"(revenue)]"

  SELECT
      region,
      sum(revenue) AS total
  FROM (
      VALUES ('us', 100), ('eu', 200), ('us', 150), ('eu', 50)
  ) AS t(region, revenue)
  GROUP BY region
  HAVING sum(total) > 100
```

Differential Revision: D97181706

## Summary by Sourcery

Revert support for resolving SELECT output aliases in HAVING clauses and
restore previous validation behavior.

Enhancements:
- Simplify OrderByExpressionRewriter by removing clause-specific error
context now that it is only used for ORDER BY.

Tests:
- Update analyzer tests to again treat alias references in HAVING as
invalid and remove related positive and error-coverage cases.


## Release Notes
Please follow [release notes
guidelines](https://github.com/prestodb/presto/wiki/Release-Notes-Guidelines)
and fill in the release notes below.

```
== RELEASE NOTES ==

General Changes
* Fix 2 bugs caused by Select Alias references in Having clause

Co-authored-by: mehradeeeepak@gmail.com <mehradeeeepak@gmail.com>