In the realm of database management, one crucial goal stands out for the PL.NET team: ensuring an exceptional developer experience. Their mission is clear—to make writing stored procedures in their environment not only effortless but also enjoyable, thus enabling the creation of powerful stored procedure applications.
In the past, numerous challenges deterred developers from delving into this territory. PL.NET, however, seeks to change that narrative by simplifying the process and providing an array of resources.

**Comprehensive Documentation**

 One of their key initiatives is to offer comprehensive documentation. Starting with a detailed FAQ section, their documentation extends to a comprehensive white paper that elucidates the system's architecture and structure. What sets them apart is their exhaustive documentation for every single data type, accompanied by illustrative examples for various usage patterns, including set-returning functions and out parameters. This meticulous documentation is designed to empower developers by providing clear and detailed insights into the system.
 
**Extensive Unit Testing:**

To further enhance the developer experience, PL.NET has invested in extensive unit testing for each feature. This means developers can not only read about how the system works but also see it in action through real-world examples. Unlike some of their counterparts, PL.NET goes the extra mile by offering a robust test suite that covers multiple scenarios, ensuring reliability and consistency.

**Seamless Transition from Client Code**

What truly sets PL.NET apart is its commitment to minimizing the gap between client code and stored procedure code. By paying close attention to type mapping with MPGSQL and adapting to the native language facilities in C# and F#, pldotnet has made it possible for developers to migrate their existing PostgreSQL client code directly into the database environment. This seamless transition eliminates the need for extensive documentation, as developers can simply leverage their existing codebase.

**The Ultimate Developer Experience**

Ultimately, the PL.NET team strives to deliver the **"my code just works" **experience. They understand that the ultimate developer experience is one where developers can rely on their code to function effortlessly, and that's precisely what they've designed for.

**Open Source Advantage:**

An additional advantage of PL.NET is its commitment to open-source principles. All of their code is open source, allowing developers to dive deep into the system and gain a comprehensive understanding of how it operates. This transparency stands in stark contrast to closed solutions like DB2 and SQL Server, where access to the underlying code is restricted.

In conclusion, PL.NET's relentless focus on enhancing the developer experience sets it apart in the world of database languages. Through comprehensive documentation, extensive testing, and a commitment to seamless code transition, they empower developers to create robust applications effortlessly. And with the advantage of open source, they not only provide a superior experience but also foster a community of collaboration and innovation.



PL.NET: Elevating Developer Experience in PostgreSQL

large_pexels-alex-fu-1188751.jpg

medium_pexels-alex-fu-1188751.jpg

small_pexels-alex-fu-1188751.jpg

thumbnail_pexels-alex-fu-1188751.jpg

pexels-alex-fu-1188751.jpg

In the ever-evolving landscape of database management, one language stands out for its versatility and innovative approach: PL.NET. Unlike its counterparts, such as IBM's DB2 and Microsoft SQL Server, PL.NET takes a unique stance by embracing multiple languages, including C#, F#, and even Visual Basic. This approach places PL.NET steps ahead of the competition.

.NET was originally designed as a multi-language environment, featuring three widely used languages. Among these, F#, while perhaps less mainstream, offers a wealth of tools for creating robust applications. It introduces Milner typing, a powerful feature that allows developers to use computer science principles to build correctness guarantees into their work. It's a curious omission, then, that DB2 and SQL Server limit themselves to supporting only C# when .NET was built with language diversity in mind.

PL.NET's superiority over SQL Server and DB2 doesn't stop at language support. It also excels in its approach to exposing database concepts naturally within the language itself. Two examples illustrate this point vividly.

The first example revolves around "inout functions." These functions handle arguments that can flow into, out of, or both into and out of a procedure or function. Although functional programming typically rejects such constructs due to their complex semantics, SQL supports them, necessitating their inclusion in PL.NET. In C#, PL.NET deftly employs C#'s native support for out parameters and reference parameters, aligning with SQL's approach. However, in F#, a functional programming language, PL.NET adapts to the functional style, maintaining separate input and output parameters.

The second example concerns "set-returning functions," where a function returns multiple rows of data, a powerful capability in a database environment. DB2's mapping of this feature is cumbersome, leaving developers to handle raw data processing and complex loop management. PL.NET streamlines this process by handling all the intricacies within the environment and elegantly mapping them to iterators in both C# and F#. C# and F# handle iterators differently, but PL.NET ensures the database behavior seamlessly aligns with each language's native patterns.

Unlike DB2, which leaves developers to wrestle with raw data and complex processing, PL.NET simplifies the experience. Developers can write such functions in just a few lines of code in PL.NET compared to the thirty lines required in DB2. This meticulous attention to detail results in a significantly improved developer experience, where clean code can take center stage. PL.NET takes care of the database complexities, allowing developers to focus solely on building their applications.

DB2, unfortunately, falls short in this regard. While improvements are needed, the lack of significant changes over the years has left a gap. PL.NET, in contrast, provides an enticing opportunity for DB2 developers to transition their stored procedure code to PostgreSQL. The move to PostgreSQL aligns with the modernization trends in the database industry, offering developers enhanced capabilities and a more seamless experience.

In summary, PL.NET's forward-thinking approach not only broadens language support but also streamlines database concepts, ensuring a superior developer experience. While DB2 and SQL Server have their merits, PL.NET's commitment to language diversity and attention to detail place it at the forefront of the database management arena, catering to the evolving needs of developers and applications.


Boosting Efficiency: PL.NET's Redefinition of Database Languages 

large_pexels-pixabay-270408.jpg

medium_pexels-pixabay-270408.jpg

small_pexels-pixabay-270408.jpg

thumbnail_pexels-pixabay-270408.jpg

pexels-pixabay-270408.jpg

In the world of database management, performance is often a critical factor when choosing a procedural language. If you've ever wondered how PL.NET measures up in terms of performance within PostgreSQL, we've got the answers. In this post, we delve into our comprehensive performance testing and what sets pldotnet apart from the competition.

First and foremost, we believe in transparency and accountability. If you're interested in the nitty-gritty details, you can find all our performance data and tests in the PL.NET white paper, available for download. We encourage you to run these tests yourself to witness the results firsthand.

Our approach to performance testing was thorough. We didn't cherry-pick scenarios where we knew PL.NET would shine. Instead, we aimed for a representative sampling of various database operations across different PostgreSQL procedural languages, including C#, F#, pl/pgsql (the native one), Perl, Python, Lua, R, Java, and more.

Our motivation was clear: to identify any potential issues and ensure that we're building top-notch software. If our performance lagged significantly behind other languages, it would be a red flag, prompting us to reevaluate and optimize our code.

So, what did we discover when we ran these performance benchmarks? The results were nothing short of impressive. PL.NET emerged as an incredibly fast performer, nearly on par with pl/pgsql, the internal stored procedural language native to PostgreSQL. 

Pl/pgsql has the advantage of operating natively within the database, leveraging PostgreSQL data types directly without the need to shuttle data between environments. Its SQL-like structure aligns seamlessly with the database's infrastructure. Yet, despite these advantages, pl/pgsql only holds a slight edge over PL.NET, and the reason is worth noting.

To ensure a fair comparison, we disabled several performance tests, particularly those related to recursive functions where PL.NET exhibited a significant performance advantage, often outperforming pl/pgsql by a factor of ten or more. While these tests demonstrated PL.NET's prowess, we wanted to maintain fairness in our benchmarking.

These excluded tests, such as recursive programming functions commonly used in functional programming, are important but not the primary use case. Thus, we turned them off for benchmarking purposes.

Remarkably, our performance was so robust that we found little need for optimization. We hadn't even begun performance tuning for PL.NET at this stage.

However, it's important to understand that in the grand scheme of things, pl/pgsql's slight performance advantage in procedural layers is overshadowed by PL.NET's overall application performance. PL.NET boasts a garbage-collected, JIT-compiled, multithreaded runtime—a stark contrast to pl/pgsql's simpler, single-threaded, and interpreted nature. When it comes to your application's overall performance, PL.NET has the upper hand.

While we acknowledge there's room for further optimization, even without it, we're neck and neck with pl/pgsql, making us highly competitive. When we do fine-tune those areas, PL.NET will undoubtedly outperform pl/pgsql, especially in scenarios where we currently outshine them.

In conclusion, PL.NET emerges as the top external stored procedural language, offering robust competition even against the native stored procedural language. When it comes to overall performance, PL.NET takes the lead. Moreover, we provide a wider range of native data type support, better testing, and improved API support. The choice is clear: PL.NET is the ultimate performer in PostgreSQL's procedural language landscape.


Redefining PostgreSQL Procedural Languages with PL.NET's Performance Excellence

large_pexels-luis-gomes-546819.jpg

medium_pexels-luis-gomes-546819.jpg

small_pexels-luis-gomes-546819.jpg

thumbnail_pexels-luis-gomes-546819.jpg

pexels-luis-gomes-546819.jpg

In the ever-evolving world of database management systems, PostgreSQL stands out as a versatile and powerful choice. But like any complex system, it comes with its fair share of challenges, particularly when it comes to handling data types and their compatibility with various programming languages. In this blog post, we'll explore the nuances of data type support in PostgreSQL and how a unique solution, PL.NET, is changing the game.

One of the fascinating aspects of PostgreSQL is its support for multiple procedural languages. However, these languages often face a common issue: lightweight type support. Many of them merely take the text version of the data type from PostgreSQL and expose it to the language. Among these languages, Tcl stands out as a prime example where you're essentially handed the text representation of data. While this approach allows for flexibility, it comes with its own set of challenges.

Inside your programming environment, you're left with the cumbersome task of processing this text to access and utilize the data. This process can be tedious and time-consuming, and it doesn't always present the data in a rich or correct manner. To illustrate this, consider the intricate task of handling dates and times.

Dealing with dates and times is a complex endeavor. Historical calendars introduce shifts in time zones, and different regions may have different variations of calendars with leap days. The divergence between the Orthodox calendar and the Western European calendar may seem minor, but it's precisely these subtleties that can lead to unexpected issues. Imagine encountering a rare bug that only triggers on January fourth of nineteen sixty; tracking down such issues becomes an arduous task.

To compound matters, each procedural language within PostgreSQL often has its own date and time system. Unless you meticulously adapt PostgreSQL dates to your language's specific format—be it Python, Java, or Lua—bugs can creep in unnoticed. This is where PL.NET steps in, making a significant difference. By leveraging the existing .NET PostgreSQL client library, NPGSQL, PL.NET provides a complete and seamless type mapping from PostgreSQL to .NET data types. Take, for instance, the handling of dates and times. NPGSQL meticulously transforms PostgreSQL date-time values into the correct .NET date-time data structures. .NET boasts comprehensive and accurate support for calendars, dates, times, and time zones.
However, it's important to note that .NET's representation isn't identical to PostgreSQL's, requiring careful adaptation. Most procedural languages leave this task to the developers, often providing PostgreSQL data as text strings and leaving you with the responsibility of adapting them to your local environment.
PL.NET differentiates itself through its use of NPGSQL, ensuring a thorough mapping of all PostgreSQL data types to .NET data types. 

This advantage extends further because it enforces data type adherence in the language itself. While languages like Python, Perl, Lua, and R remain untyped, PL.NET's strong data type enforcement guarantees correct mappings.

Additionally, PL.NET supports a broader range of native data types than most other procedural languages. The only comparable languages are those like Tcl, which essentially hand you the raw PostgreSQL value as a text representation—not true type support.

In PL.NET, you can expect dates and times that adhere to .NET conventions, making them compatible with all .NET libraries. This mapping is done with precision, and the codebase's reliability is backed by NPGSQL's mature and widespread use in the PostgreSQL community. When it comes to data type support in PostgreSQL, we firmly believe that PL.NET is unparalleled, offering the best support available today.

In summary, while PostgreSQL's support for procedural languages is a powerful feature, handling data types can be a complex and error-prone task. PL.NET addresses these challenges by providing a comprehensive and reliable mapping of PostgreSQL data types to .NET data types, backed by strong type enforcement within the language itself. This approach ensures that you can work with PostgreSQL data seamlessly in your .NET development environment, making PL.NET the top choice for data type support in PostgreSQL.


large_pexels-markus-spiske-330771.jpg

medium_pexels-markus-spiske-330771.jpg

small_pexels-markus-spiske-330771.jpg

thumbnail_pexels-markus-spiske-330771.jpg

pexels-markus-spiske-330771.jpg

Why PL.NET Has Amazing Type Support

When it comes to speed, our benchmarks evaluate the performance of all PostgreSQL stored procedure languages in their capacity to efficiently move data in and out of the database while carrying out computations. These benchmarks specifically gauge how well PL.NET bridges the gap between these two environments.

In these tests, we find ourselves in a remarkable position – we are tied for the title of the fastest stored procedure language. It's an impressive tie with PostgreSQL's native stored procedure language, known as pl/pgsql. However, it's crucial to note that this tie in speed pertains only to the procedural language benchmarks. In the broader scope, PL.NET outperforms pl/pgsql by a significant margin. This superiority is attributed to several factors: PL.NET is compiled, strongly-typed, and supports multi-threading, embodying all the attributes you'd expect from a modern language runtime. In contrast, pl/pgsql lacks these essential features.

Furthermore, pl/pgsql falls short as a developer-friendly programming environment. It doesn't even qualify as a distinct programming language; instead, it functions as an extension of the PostgreSQL database and SQL.  Its imperative language extensions atop SQL are relatively basic compared to the robust capabilities of C# or F#. The development and debugging tools for pl/pgsql pale in comparison, and it lacks libraries, resulting in a subpar experience for developers.

So, the fact that we are on par with pl/pgsql in terms of speed, particularly in its area of strength, which is its close integration with PostgreSQL, speaks volumes. In reality, we surpass it comprehensively in overall performance. In fact, we outshine every other language within the PostgreSQL ecosystem. To put it simply, we are exceptionally fast.



large_pexels-markus-spiske-1089438.jpg

medium_pexels-markus-spiske-1089438.jpg

small_pexels-markus-spiske-1089438.jpg

thumbnail_pexels-markus-spiske-1089438.jpg

pexels-markus-spiske-1089438.jpg

How Fast Is PL.NET



Brick Abode, a team of computer science enthusiasts, embarked on a quest to find the perfect environment for building full-featured applications while embracing their love for theoretical computer science. Their passion for theoretical computer science is deeply rooted in its ability to enable robust engineering and the development of applications with stringent guarantees of correctness—a formidable challenge in its own right. Theoretically, it's an infinitely complex problem. In the realm of theoretical computer science, these challenges are encapsulated within a Turing complete framework, equivalent to solving the most intricate computational problems. To tackle this, they needed tools that could empower them to construct these ironclad assurances of application correctness, and that's where functional programming stepped in.

Their quest for robustness led them to explore functional programming languages, particularly Haskell and Ocaml, both known for their strong type systems. However, upon closer inspection, they discovered that these languages lacked robust web development environments, offering weak frameworks and libraries. While it was possible to accomplish some tasks, it often entailed considerable manual effort. 

Just when it seemed they might have hit a dead end, they remembered the existence of F#. F# within the .NET ecosystem shared many similarities with Haskell and Ocaml, notably in its ability to establish type-based guarantees for program behavior and facilitate formal correctness proofs. However, what set F# apart was its integration with one of the world's largest web platforms—ASP.  ASP was not just popular; it was exceptionally well-crafted. 

Comparing this to other mature web frameworks like Django in Python, a popular choice in its own right, revealed a significant difference. Django, despite its strengths, appeared somewhat frozen in time, designed for a web landscape reminiscent of the mid-2000s. It struggled to adapt to modern web paradigms, such as handling websockets and managing URLs that could serve both APIs and HTML pages. This rigidity became apparent when dealing with technologies like React or the demands of financial applications with substantial data flows that relied on websockets. 

Django's Model-View-Controller (MVC) approach, while effective in its own right, seemed rudimentary in the face of modern web development's increasingly clear separation of front-end and back-end concerns. ASP, on the other hand, offered a different narrative. Despite its origins dating back to the late '90s, Microsoft continuously innovated and improved ASP over the years. The result was a remarkably modern web framework. ASP excelled in supporting APIs, seamlessly integrating with React, and embracing websockets—a crucial aspect of the contemporary web landscape. It demonstrated a modular and flexible approach to managing APIs and pages concurrently, providing an agile solution for URL routing.

For Brick Abode, the choice became evident. ASP, despite its longer history, had evolved into a powerful modern framework that outpaced Django in various aspects. The team found that building applications in ASP was not only cost-effective but also delivered higher quality and faster development speed. Additionally, ASP's robustness allowed for swift codebase refactoring and transitioning between different approaches, making it the preferred choice for serious web application development. 

The decision wasn't singular; it stemmed from a combination of factors. ASP's strong typing, modular routing, enhanced front-end and back-end separation, and myriad other advantages made it the ideal platform for the challenges Brick Abode sought to conquer in the world of web development.


Brick Abode's Journey into the World of DotNET and Functional Programming

Brick Abode's Journey into the World of DotNet and Functional Programming


For decades, the world of software development has seen the rise of applications built upon the foundation of stored procedures. These procedures, when harnessed effectively, have the potential to create truly remarkable and high-performing applications.

From a computer science standpoint, it becomes evident that stored procedures offer a logical approach to handling the interplay between programs and data. If you pause to reflect, both a program and data share a common essence—they are, at their core, data. Each can be neatly confined within the confines of a thumb drive, represented by the binary language of zeros and ones. So, what sets them apart? In essence, it's a matter of scale. Typically, a program is dwarfed by the data it operates upon. If it were the other way around, you'd merely execute the program and directly utilize the resulting data, bypassing the need to run the program separately.

Therefore, in nearly every scenario, the program is inherently smaller than the data it manipulates. Yet, in the realm of computing, a curious phenomenon often occurs. Instead of transporting the more compact program to the vast expanse of data, we find ourselves hauling the substantial data to accommodate the program's limitations.

You might wonder why such a seemingly counterintuitive approach persists. The answer lies in the complexity of building applications with stored procedures. This approach can be arduous for various reasons. In a nutshell, it boils down to the challenging development environment—an environment that offers little solace to developers seeking to craft applications with finesse.

Looking back to the 1980s and early 1990s, this approach made sense. Relational databases were still in their infancy, the tools and programming languages were rudimentary at best. It was during this era that stored procedures earned a somewhat tarnished reputation. 

However, it's crucial to recognize that this unfavorable image stemmed from the technological limitations of the late 1980s, not an inherent flaw in the concept of stored procedures. There are situations where stored procedures shine brilliantly.

Enter PL.NET. We posed a fundamental question: What if we merge a modern programming environment with a well-structured stored procedure system? What kind of development experience could we create? Our belief then, as it is now, remains unwavering: it can be an exceptional developer experience.

That's precisely the mission of PL.NET. It seamlessly marries one of the world's finest relational databases, PostgreSQL, with what we firmly believe to be one of the most robust application and web development frameworks— .NET. This fusion enables us to construct applications in a manner where the code coexists harmoniously with the data, instead of requiring data to be forcibly moved to accommodate the code. Consequently, this approach empowers us to craft applications that not only perform exceptionally well but also boast robust security. Moreover, it unlocks novel application patterns, all thanks to the symbiotic relationship between the programming environment and the data, allowing computation to occur in close proximity to the data. 

In this new era of software development, the code comes to the data, and with it, a world of possibilities unfolds.
