PL/SQL Archives - Philipp Salvisberg's Blog https://www.salvis.com/blog/tag/plsql/ Database-centric development Mon, 12 Oct 2026 18:40:51 +0000 en-US hourly 1 https://wordpress.org/?v=7.1.3 https://www.salvis.com/blog/wp-content/uploads/2014/04/favicon.png PL/SQL Archives - Philipp Salvisberg's Blog https://www.salvis.com/blog/tag/plsql/ 32 32 The Checkbox That Disables TLS https://www.salvis.com/blog/2026/08/23/the-checkbox-that-disables-tls/ https://www.salvis.com/blog/2026/08/23/the-checkbox-that-disables-tls/#respond Sun, 23 Aug 2026 21:20:28 +0000 https://www.salvis.com/blog/?p=23591 Introduction The dbLinter clients include a new setting named Allow Insecure TLS. It is disabled by default. As a result, all REST API calls verify the TLS certificate and hostname. The setting allows dbLinter to work in organisations that inspect TLS traffic using tools such as Zscaler. In larger organisations, arranging an […]

The post The Checkbox That Disables TLS appeared first on Philipp Salvisberg's Blog.

]]> Introduction

The dbLinter clients include a new setting named Allow Insecure TLS. It is disabled by default. As a result, all REST API calls verify the TLS certificate and hostname.

The setting allows dbLinter to work in organisations that inspect TLS traffic using tools such as Zscaler.

In larger organisations, arranging an inspection bypass can be cumbersome and is often too much effort for an ad-hoc trial of dbLinter. The checkbox provides a temporary workaround and should be enabled only on a trusted network.

However, allowing insecure TLS on untrusted networks, such as open Wi-Fi without client isolation, can let an attacker redirect traffic through their own machine using techniques like ARP spoofing. The attacker can also operate the access point themselves, for example, by creating a rogue Wi-Fi hotspot.

In this blog post, I demonstrate the effect of this checkbox.

Allow Insecure TLS

The latest version of dbLinter for VS Code has a checkbox that disables certificate and hostname verification.

Allow Insecure TLS Checkbox in VS Code

dbLinter’s allowInsecureTls setting is nothing unusual. Many common tools offer a similar option, including curl (--insecure), wget (--no-check-certificate), and git (--config http.sslVerify false).

Installing and Configuring a Proxy

I run this demo on macOS 26.6.2.

A simple proxy is mitmweb. We can install and configure it as follows:

brew install mitmproxy
networksetup -setsecurewebproxy "Wi-Fi" 127.0.0.1 8090
mitmweb --listen-port 8090 --web-port 8091 --allow-hosts '^api\.dblinter\.app'
[20:36:20.907] HTTP(S) proxy listening at *:8090.
[20:36:20.908] Web server listening at http://127.0.0.1:8091/?token=f83b02032aaaccd282ad3925a484fcdb

The mitmweb command starts the proxy and listens on port 8090 for TLS traffic between localhost and api.dblinter.app. All other traffic is bypassed.

The mitmweb proxy also opens the following web page:

mitmproxy after start up

Intercepting Traffic

To generate traffic, we launch VS Code and open a SQL file. This produces the following in the output panel for dbLinter:

2026-08-23 20:37:43.216 [Info ] Starting dbLinter Language Server.
2026-08-23 20:37:43.539 [Info ] connect.
2026-08-23 20:37:43.611 [Info ] initialize VSCode 1.10.0.
2026-08-23 20:37:43.646 [Info ] didOpen file:///.../dbl_client_types.sql.
2026-08-23 20:37:43.651 [Info ] AntlrCacheCoordinator initialized with parallel degree 1 and clearCacheThreshold 2048 of 16384 MB.
2026-08-23 20:37:43.671 [Warn ] TLS certificate and hostname verification are disabled for dbLinter repository API calls. Use this temporary workaround only when TLS interception cannot be bypassed.
2026-08-23 20:37:45.533 [Info ] Configuration dbLinter of tenant Grisselbav loaded with 294 check methods.
2026-08-23 20:37:45.534 [Info ] didChangeConfiguration.
2026-08-23 20:37:45.703 [Info ] tests returned 43 tests.
2026-08-23 20:37:45.796 [Info ] parseAndCheck file:///.../dbl_client_types.sql.
2026-08-23 20:37:45.910 [Info ] hasFeature Config returned true.
2026-08-23 20:37:46.286 [Info ] parseAndCheck completed in 0.489 sec including 0.052 sec for checks.
2026-08-23 20:37:46.289 [Info ] diagnostics for file:///.../dbl_client_types.sql with 2 issues.

The log contains a warning that TLS certificate and hostname verification are disabled.

dbLinter analyses SQL and APEXlang files locally. The captured traffic lets us verify what is sent to the dbLinter API. It contains the API key and session data, but not the contents of the analysed files. The source code therefore remains within the local network.

mitmproxy request message

It goes without saying that it is not good to expose the API key in plain text.

The proxy also shows the decrypted response:

mitmproxy response message

The session object in the response contains a signature. The client can therefore detect changes to the signed content, including the validators. This prevents the proxy from silently modifying the validators or injecting malicious code. However, the signature does not prevent the proxy from reading the request and response.

Enforce TLS Verification

Now let’s uncheck the Allow Insecure TLS checkbox and execute the Reload Window command.

disallow insecure TLS in VS Code

This produces the following in the output panel for dbLinter:

2026-08-23 20:52:37.281 [Info ] Starting dbLinter Language Server.
2026-08-23 20:52:37.550 [Info ] connect.
2026-08-23 20:52:37.606 [Info ] initialize VSCode 1.10.0.
2026-08-23 20:52:38.047 [Info ] didOpen file:///.../dbl_client_types.sql.
2026-08-23 20:52:38.049 [Info ] AntlrCacheCoordinator initialized with parallel degree 1 and clearCacheThreshold 2048 of 16384 MB.
2026-08-23 20:52:38.375 [Error] Failed to load configuration.

org.springframework.web.client.ResourceAccessException: I/O error on POST request for "https://api.dblinter.app/api/client-session/open": (certificate_unknown) PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

The proxy presented a certificate for api.dblinter.app which was not issued by a trusted certification authority.

The proxy console therefore shows the following log entry:

[20:52:38.217][127.0.0.1:60439] server connect api.dblinter.app:443 (91.98.90.2:443)
[20:52:38.360][127.0.0.1:60441] client connect
[20:52:38.375][127.0.0.1:60439] Client TLS handshake failed. The client does not trust the proxy's certificate for api.dblinter.app (OpenSSL Error([('SSL routines', '', 'ssl/tls alert certificate unknown')]))
[20:52:38.377][127.0.0.1:60439] client disconnect
[20:52:38.380][127.0.0.1:60439] server disconnect api.dblinter.app:443 (91.98.90.2:443)

The REST API call failed before the proxy received the HTTP request. Therefore, the API key and other request data were not exposed.

Reset Network Configuration and Uninstall Proxy

Let’s stop the proxy by pressing Ctrl-C in the terminal window running it. Then run the following:

networksetup -setsecurewebproxystate "Wi-Fi" off
brew uninstall mitmproxy
rm -rf ~/.mitmproxy

Conclusion

The Allow Insecure TLS option solves a practical problem in environments where TLS inspection cannot easily be bypassed. However, it disables certificate and hostname verification. A proxy or an attacker controlling the network can then read requests, including the API key.

The captured traffic also confirms that dbLinter analyses SQL and APEXlang files locally. Signed server responses protect the downloaded configuration from manipulation, but they do not protect confidential request data.

Therefore, enable this option only as a temporary workaround on a trusted network. The preferred solution is to configure a TLS inspection bypass. Disable the option again as soon as possible.

The post The Checkbox That Disables TLS appeared first on Philipp Salvisberg's Blog.

]]> https://www.salvis.com/blog/2026/08/23/the-checkbox-that-disables-tls/feed/ 0 Fighting Bad PL/SQL & SQL with VS Code https://www.salvis.com/blog/2026/01/02/fighting-bad-pl-sql-sql-with-vs-code/ Fri, 02 Jan 2026 21:05:10 +0000 https://www.salvis.com/blog/?p=14289 The success of a project or product depends largely on the quality of the code. But how can I improve security, maintainability or performance? More importantly, how can I prevent code with quality defects from entering production? In addition to testing, code analysis plays a central role. These days, code can be […]

The post Fighting Bad PL/SQL & SQL with VS Code appeared first on Philipp Salvisberg's Blog.

]]> The success of a project or product depends largely on the quality of the code. But how can I improve security, maintainability or performance? More importantly, how can I prevent code with quality defects from entering production? In addition to testing, code analysis plays a central role. These days, code can be checked not only in CI/CD pipelines, but also during development. Modern IDEs, such as Visual Studio Code, can automatically detect quality issues and offer quick fixes. The goal is a fast feedback loop.

This blog post is based on my German article with the same title, published in issue 1/2026 of the Red Stack Magazin.

Measuring Software Quality

Imagine you are part of a team where code changes to a feature or bug fix branch are only merged into the develop or main branch following a review. Sometimes you are the author and sometimes one of the reviewers. I am currently part of a team that works in this way. In addition to quality assurance, knowledge sharing is also an important aspect. But how can we assess code quality?

Figure 1: WTFs/m

This well-known meme by Thom Holwerda says, “The only valid measurement of code quality is WTFs per minute.” This seems to be a good metric. However, this metric does have some flaws.

  • It is subjective.
  • It does not provide any information about what is being assessed.
  • It does not help new team members to adapt quickly.
  • And it cannot be automated in a meaningful way.

Sooner or later, a team has no choice but to agree on a set of rules. They can be informal or formal. Typical coding guidelines cover topics such as naming conventions, formatting, code complexity, and language usage rules. The aim is to define and comply with quality standards relating to maintainability, reliability, performance and security. Written coding guidelines also simplify the onboarding of new team members.

Automation

Manually checking compliance with coding guidelines as part of a review is so time-consuming that no one can afford to do it properly. Therefore, we have to automate as many checks as possible. This is possible for many aspects. The rest still have to be checked manually.

In other words, we need a tool suite for automatic rule checking. dbLinter is such a tool suite. It is a new product developed and continuously improved by Grisselbav and United Codes. dbLinter uses the IslandSQL parser, which is updated quarterly with every release update of the Oracle AI Database for SQL, PL/SQL, SQL*Plus and SQLcl.

dbLinter is the successor to the decommissioned db* CODECOP suite. dbLinter consists of a central repository, a web GUI and client tools. These include a CLI, a SonarQube plugin and a VS Code extension.

Visual Studio Code Extension

The VS Code extension is compatible with all IDEs that implement the Visual Studio Code Extension API. Specifically: Visual Studio Code, Theia IDE, VSCodium, Cursor, Windsurf, Void, Kiro and Antigravity.

dbLinter for VS Code is available in both the Visual Studio Marketplace and the Open VSX Registry. Therefore, it can be conveniently installed directly from the IDE. The extension is free to use as part of the Anonymous and Starter plans (see dbLinter Pricing Plans).

It is important to note that your code is always analysed locally, meaning that it never leaves your network. The configuration is read from the central repository, enabling the client to identify the active rules and parameters. These configurations, along with others, are managed using the Web GUI.

Figure 2: dbLinter rule configuration in the Web GUI

dbLinter currently offers 187 rules. This includes all the rules from the decommissioned Trivadis PL/SQL & SQL Coding Guidelines. Figure 2 shows the configuration of my 14 favourite rules. A violation of one of these rules is a bug. There is almost no room for interpretation here. The following chapters provide two examples.

Top-N Queries with ROWNUM

The query in Listing 1 is based on the well-known EMP table owned by the database user SCOTT. It returns two rows.

Listing 1: Defective pre-12c-style top-n query
select ename,
       sal,
       hiredate,
       rownum as rank
  from emp
 where rownum <= 2
 order by sal desc;
ENAME             SAL HIREDATE         RANK
---------- ---------- ---------- ----------
ALLEN            1600 20.02.1981          2
SMITH             800 17.12.1980          1

However, the result barely meets the requirements. I would have expected the two employees with the highest salaries to be returned. Why is this not the case? The query is formulated in such a way that two rows are randomly selected and then sorted in descending order by salary. The result depends on the execution plan and the physical storage of the data.

Figure 3: Violation of rule G-3185 in VS Code

In VS Code, rule violations are displayed under Problems (see Figure 3). There is also a Core G-3185 link that opens the rule details in the Web GUI.

Figure 4: Rule G-3185 in the dbLinter Web GUI

Rule G-3185 in the web GUI is explained based on a similar case in the HR schema (see Figure 4). There are two solutions here. One that can be applied in all Oracle Database versions and one that works from version 12c onwards. Listing 2 shows the traditional solution, which uses an inline view. Of course, nowadays I would always prefer a solution using the row_limiting_clause.

We can also see that the rule is used in six configurations. Clicking on “(details)” opens a pop-up window in which changes can be made. This allows you to configure the rules directly from the IDE.

Listing 2: Fixed pre-12c-style top-n query
select e.*,
       rownum as rank
  from (
          select ename,
                 sal,
                 hiredate
            from emp
           order by sal desc
       ) e
 where rownum <= 2;
ENAME             SAL HIREDATE         RANK
---------- ---------- ---------- ----------
KING             5000 17.11.1981          1
SCOTT            3000 19.04.1987          2

NVL vs. COALESCE

One often underestimated rule is “G-4230: Always use a COALESCE instead of a NVL command, if parameter 2 of the NVL function is a function call or a SELECT statement”. This rule is about performance, which is relevant to all of us, especially when it is poor. This is why this rule is important.

Listing 3: Bad performance with NVL
with
   function slow_function return integer is
   begin
      sys.dbms_session.sleep(0.2);
      return null;
   end slow_function;
select ename, nvl(mgr, slow_function()) as mgr
  from emp;

Listing 3 demonstrates a case in which the use of NVL results in an execution time of approximately 2.8 seconds. If COALESCE is used instead of NVL, the execution time is only about 0.2 seconds. The reason is that NVL always evaluates the second parameter, even if the first parameter is not null. COALESCE works differently: the second parameter is only evaluated if the first parameter is null. This performance difference originates from the fact that the EMP table contains 14 rows, but only one of these returns an empty MGR.

In this case, using COALESCE is definitely the better solution. So, should NVL always be replaced by COALESCE? No. There are two special cases:

  1. NVL supports implicit data type conversion.
    select nvl(mgr, '1') from emp works, but select coalesce(mgr, '1') from emp causes an ORA-00932 error. However, implicit type conversions should be avoided anyway. The code should be adjusted accordingly.
  2. Optimisations of NVL can lead to better execution plans.
    Such optimisations currently only exist for NVL and not for COALESCE. Therefore, it is better to continue using NVL in these cases. See The Magical NVL Function by Monika Lewandowska for an example.
Quick Fixes

dbLinter knows these special cases. It offers appropriate alternative solutions. See Figure 5.

Figure 5: Quick fixes for G-4230 violation in VS Code.

dbLinter can apply quick fixes to different sections. For example, for a single violation of a rule, for all violations of a rule, or for all violations of all rules in the editor window.

The “@dbLinter ignore markers” are special comments used to ignore rule violations. There are various legitimate reasons for doing this. For example, in the case of false positives (dbLinter bugs) or exceptions to the rule. A comment such as -- @dbLinter ignore(G-4230): NVL forever can have the following scopes: line, statement or file, depending on where the comment is positioned.

Code Analysis and AI

The solution proposals in Figure 5, indicated by the yellow lamp symbol, are quick fixes from dbLinter. However, the last two menu options come from GitHub Copilot.

When Copilot suggests a solution to a rule violation, dbLinter provides the necessary context, including the file and the exact location of the violation, as well as the name of the violated rule. This gives Copilot access to the rule definition online, enabling it to suggest a reasonable solution in many cases. In other words, dbLinter enhances the support offered by tools such as Copilot, Cline and Windsurf.

Rules are useful for AI tools. They provide a framework that leads to better results. However, there is no guarantee that all rules will be followed. Ultimately, code generated or expanded by AI becomes part of our code base. This is why it is important to check AI-generated code according to the same rules as manually created code.

In other words, AI does not enforce standards. But dbLinter can do that.

Conclusion

Software quality is a matter of definition. dbLinter offers many rules. Not all of them are useful and applicable to every project. The dbLinter rules can therefore be seen as a large buffet. You choose what you like and what is healthy. But not too much at once. Nevertheless, there are some rules that, in my opinion, should be followed in every project. I have presented two of them in this blog post.

Install dbLinter for VS Code to identify the rules that will be most helpful for your projects. The rules in Figure 2 are certainly a good starting point.

If you have any questions, please feel free to contact me. Alternatively, you can create issues directly in the dbLinter GitHub repository.

The post Fighting Bad PL/SQL & SQL with VS Code appeared first on Philipp Salvisberg's Blog.

]]> Is SYSDATE Deterministic? #JoelKallmanDay https://www.salvis.com/blog/2025/10/15/is-sysdate-deterministic-joelkallmanday/ https://www.salvis.com/blog/2025/10/15/is-sysdate-deterministic-joelkallmanday/#comments Tue, 14 Oct 2025 22:00:00 +0000 https://www.salvis.com/blog/?p=14035 TL;DR No, SYSDATE is not deterministic. However, it behaves very similarly to a deterministic function within an Oracle Database SQL statement. Background On a customer site, we used faketime on the OS to change the date and time for testing purposes. As long as you only travel forward in time, the Oracle […]

The post Is SYSDATE Deterministic? #JoelKallmanDay appeared first on Philipp Salvisberg's Blog.

]]> TL;DR

No, SYSDATE is not deterministic. However, it behaves very similarly to a deterministic function within an Oracle Database SQL statement.

Background

On a customer site, we used faketime on the OS to change the date and time for testing purposes. As long as you only travel forward in time, the Oracle Database behaves fine. The solution worked well for the last 8 years. However, this approach had some drawbacks, such as the need for a full-blown VM (we cannot change the time in an isolated manner within a Docker container), disabling time synchronisation processes and issues with third-party software due to failed sanity/license checks. This approach prevented us from simplifying the architecture of the testing environment.

We were exploring alternatives to travel in time only within the Oracle Database. One option was to set FIXED_DATE, and another to replace calls to SYSDATE, SYSTIMESTAMP, CURRENT_DATE, CURRENT_TIMESTAMP and LOCALTIMESTAMP with custom functions that added an offset to the current date/time. For the latter, I’d like to share some simplified test results.

But before that, let’s look at some definitions.

Definitions

Wikipedia defines a deterministic algorithm in computer science as follows:

In computer science, a deterministic algorithm is an algorithm that, given a particular input, will always produce the same output, with the underlying machine always passing through the same sequence of states. Deterministic algorithms are by far the most studied and familiar kind of algorithm, as well as one of the most practical, since they can be run on real machines efficiently.

The Oracle Database PL/SQL Language Reference defines deterministic for the deterministic_clause as follows:

  • A function is deterministic if the DETERMINISTIC clause appears in either a declaration or the definition of the function.
  • The DETERMINISTIC clause may appear at most once in a function declaration and at most once in a function definition.
  • A deterministic function must return the same value on two distinct invocations if the arguments provided to the two invocations are the same.
  • A DETERMINISTIC function may not have side effects.
  • A DETERMINISTIC function may not raise an unhandled exception.
  • If a function with a DETERMINISTIC clause violates any of these semantic rules, the results of its invocation, its value, and the effect on its invoker are all undefined.

How to Check?

There are two ways to check if a function is deterministic. Firstly, you can query the data dictionary like this:

1) Query Data Dictionary
select deterministic 
  from dba_procedures
 where procedure_name = 'SYSDATE';
DETERMINISTIC
-------------
NO

Secondly, you can check the source code to see if it contains a deterministic_clause. SYSDATE is defined in the STANDARD package as a wrapper to the kernel function pessdt and has no deterministic_clause.

2) STANDARD specification excerpt
create or replace package STANDARD AUTHID CURRENT_USER is …
  function SYSDATE return DATE;
    pragma FIPSFLAG('SYSDATE', 1452); …
end;

3) STANDARD body excerpt
create or replace package body STANDARD is …
  -- Bug 1287775: back to calling ICD.
  -- Special: if the ICD raises ICD_UNABLE_TO_COMPUTE, that means we should do
  -- the old 'SELECT SYSDATE FROM DUAL;' thing.  This allows us to do the
  -- SELECT from PL/SQL rather than having to do it from C (within the ICD.)
  function sysdate return date is
    d date;
  begin
    d := pessdt;
    return d;
  exception
    when ICD_UNABLE_TO_COMPUTE then
      select sysdate into d from sys.dual;
      return d;
  end; …
end;

So, SYSDATE is clearly non-deterministic.

Interesting are the comments regarding bug 1287775 (APPSST:PERF: SERVER SIDE PL/SQL SHOULD NOT USE SQL TO OBTAIN SYSDATE). It does not seem to be entirely about performance. The last update of the bug was in mid-2021. I was unable to find out why a pessdt call may fail, and why getting SYSDATE via a query from dual should solve the problem. Anyway, it’s not essential for this blog post.

Comparing SYSDATE to a Non-Deterministic Function

Let’s create a non-deterministic function APPDATE that returns SYSDATE. Then, we compare the SYSDATE and APPDATE results in a PL/SQL cursor.

4) Non-deterministic APPDATE
create or replace function appdate return date is
begin
  return sysdate;
end;
/

set serveroutput on size unlimited
set arraysize 1
declare
   cursor c is 
        select rownum,
               to_char(sysdate, 'YYYY-MM-DD HH24:MI:SS') as the_sysdate, 
               to_char(appdate, 'YYYY-MM-DD HH24:MI:SS') as the_appdate
          from user_objects
         where rownum <= 5;
   r c%rowtype;     
begin
    open c;
    sys.dbms_output.put_line('# THE_SYSDATE         THE_APPDATE');
    sys.dbms_output.put_line('- ------------------- -------------------');
    loop
        fetch c into r;
        exit when c%notfound;
        sys.dbms_output.put_line(r.rownum || ' ' || r.the_sysdate || ' ' || r.the_appdate);
        sys.dbms_session.sleep(1);
    end loop;
    close c;
end;
/
Function APPDATE compiled

# THE_SYSDATE         THE_APPDATE
- ------------------- -------------------
1 2025-10-13 08:28:29 2025-10-13 08:28:29
2 2025-10-13 08:28:29 2025-10-13 08:28:30
3 2025-10-13 08:28:29 2025-10-13 08:28:31
4 2025-10-13 08:28:29 2025-10-13 08:28:32
5 2025-10-13 08:28:29 2025-10-13 08:28:33


PL/SQL procedure successfully completed.

You see, the results are different except for the first row. We had to set the fetch array size to one to ensure the sleep call on line 25 affects each fetched record. Otherwise, you would see the effect between the batch of records defined by the default fetch size.

Comparing SYSDATE to a Deterministic Function

Let’s make the APPDATE function deterministic and rerun the script.

5) Deterministic APPDATE
create or replace function appdate return date deterministic is
begin
  return sysdate;
end;
/

set serveroutput on size unlimited
set arraysize 1
declare
   cursor c is 
        select rownum,
               to_char(sysdate, 'YYYY-MM-DD HH24:MI:SS') as the_sysdate, 
               to_char(appdate, 'YYYY-MM-DD HH24:MI:SS') as the_appdate
          from user_objects
         where rownum <= 5;
   r c%rowtype;     
begin
    open c;
    sys.dbms_output.put_line('# THE_SYSDATE         THE_APPDATE');
    sys.dbms_output.put_line('- ------------------- -------------------');
    loop
        fetch c into r;
        exit when c%notfound;
        sys.dbms_output.put_line(r.rownum || ' ' || r.the_sysdate || ' ' || r.the_appdate);
        sys.dbms_session.sleep(1);
    end loop;
    close c;
end;
/
Function APPDATE compiled

# THE_SYSDATE         THE_APPDATE
- ------------------- -------------------
1 2025-10-13 08:29:00 2025-10-13 08:29:00
2 2025-10-13 08:29:00 2025-10-13 08:29:00
3 2025-10-13 08:29:00 2025-10-13 08:29:00
4 2025-10-13 08:29:00 2025-10-13 08:29:00
5 2025-10-13 08:29:00 2025-10-13 08:29:00


PL/SQL procedure successfully completed.

Now we have the same result. SYSDATE is evaluated once for the whole query as the deterministic function APPDATE. There is obviously some special treatment of SYSDATE in the Oracle Database code for SQL statements. It handles it similarly to a deterministic function or a bind variable. That’s good. This matches the read consistency concepts. We do not want to get different results of SYSDATE in a single query.

But how does it behave in PL/SQL?

SYSDATE in PL/SQL

24 years ago, someone posted a puzzle in the forum of dbasupport.com that covered the same topic. I snitched the code from there and adapted it slightly.

6) SYSDATE endless-Loop?
set serveroutput on size unlimited
declare
   i binary_integer := 0;
begin
   while sysdate = sysdate loop
      i := i + 1;
   end loop;
   dbms_output.put_line('Left the loop after ' || i || ' iterations');
end;
/
Left the loop after 2957099 iterations


PL/SQL procedure successfully completed.

It appears to be an endless loop, but it is not. The two SYSDATE calls are evaluated independently, and eventually they return different results. Of course, the number of iterations varies. Therefore, the algorithm could be used as a kind of random number generator.

APPDATE in PL/SQL

Let’s use the deterministic variant of the APPDATE function in the same script.

7) APPDATE endless-Loop?
create or replace function appdate return date deterministic is
begin
  return sysdate;
end;
/

set serveroutput on size unlimited
declare 
   i binary_integer := 0;
begin
   while appdate = appdate loop
      i := i + 1;
   end loop;
   dbms_output.put_line('Left the loop after ' || i || ' iterations');
end;
/
Function APPDATE compiled

declare 
*
ERROR at line 1:
ORA-01426: numeric overflow
ORA-06512: at line 5

https://docs.oracle.com/error-help/db/ora-01426/


More Details :
https://docs.oracle.com/error-help/db/ora-01426/
https://docs.oracle.com/error-help/db/ora-06512/

Luckily, the maximum value of a binary integer is 2,147,483,647. With a NULL statement on line 12, the script would run endlessly. It looks like the APPDATE function is evaluated only once within the WHILE statement.

We told the PL/SQL compiler that the APPDATE function is deterministic. So the same input (none in this case) always produces the same output. This is a lie. However, the compiler is a nice component and trusts us. So it can come up with some optimisations to improve the runtime of our code and produce a solution that calls APPDATE only once. And boom, we have an endless loop.

Let’s verify this.

PLSQL_OPTIMIZE_LEVEL

The PL/SQL compiler knows the following four optimisation levels:

  • 0 = Oracle Database 9i style with some minor improvements
  • 1 = Various optimisations, does not move code, therefore required when debugging PL/SQL
  • 2 = More optimisations, including moving code around, this is the default in 19c/23ai
  • 3 = Even more optimisations

The documentation leaves us in the dark about what each level does exactly. However, one thing is sure. The higher the level, the more aggressive the optimisation.

So let’s try the previous code with level 0.

8) APPDATE endless-Loop with plsql_optimize_level 0?
alter session set plsql_optimize_level = 0;
create or replace function appdate return date deterministic is
begin
  return sysdate;
end;
/

set serveroutput on size unlimited
declare 
   i binary_integer := 0;
begin
   while appdate = appdate loop
      i := i + 1;
   end loop;
   dbms_output.put_line('Left the loop after ' || i || ' iterations');
end;
/
Session altered.


Function APPDATE compiled

Left the loop after 3224661 iterations


PL/SQL procedure successfully completed.

Ha, this worked. No endless loop. We get a similar result with level 1. However, levels 2 and 3 lead to an endless loop.

This example should illustrate that we should not lie to the compiler. Sooner or later, another optimisation in a newer version could break our code.

Conclusion

In fact, the previous paragraph could be a good conclusion. However, at the beginning of this post, I mentioned a real use case where we were evaluating an alternative to the faketime library. We opted for FIXED_DATE because it is simple to apply and worked for the application under test. The application uses SYSDATE exclusively for business-relevant dates and times. SYSTIMESTAMP, CURRENT_DATE, CURRENT_TIMESTAMP and LOCALTIMESTAMP, which are unaffected by FIXED_DATE, are used only for logging purposes.

The idea of providing a custom function that returns SYSDATE with a centrally defined offset might have worked in our case. But providing a solution that behaves like SYSDATE is much more challenging than I thought. We would need something that is evaluated once in a SQL statement and per call in other cases. Passing SYSDATE as a default parameter to a deterministic function does the trick. Either way, I’m glad we opted for the simpler solution, which meant there was no need to change the code base.

The post Is SYSDATE Deterministic? #JoelKallmanDay appeared first on Philipp Salvisberg's Blog.

]]> https://www.salvis.com/blog/2025/10/15/is-sysdate-deterministic-joelkallmanday/feed/ 3