Earlier quoted context omitted.
All enterprise level RDMS have similar capabilities, some of which are yet to come to Postgres.
Postgres is currently the most advanced RDMS, anyone who's not locked in by Oracle or whatever and doesn't use Postgres for new projects is likely misinformed. Postgres essentially made every other RDMS obsolete except for some niche circumstantial cases (e.g. vendor lock-in) > enterprise level Postgres is enterprise level (whatever that means). Blazingly fast, Web 3, cloud-native, etc etc, pick your own buzzwords
Prolog language for PostgreSQL proof of concept
61–70 of 83 posts
Re: Prolog language for PostgreSQL proof of concept
#62Earlier quoted context omitted.
I was wondering how this was possible and then found this monstrosity: https://colab.research.google.com/github/EvgSkv/logica/blob/... Click on the SQL tab.
I wrote SQL queries twice that long for credit originations reports in banks which would hit several terabytes of disk read per run
> Among database theoreticians Datalog and SQL are known to be equivalent. And indeed the conversion from Datalog to SQL and back is often straightforward.
I was skeptical, and indeed the sample I linked to shows 8 lines of Datalog turning into 265 lines of SQL. In defense of SQL, I note WITH RECURSIVE wasn't used.
Re: Prolog language for PostgreSQL proof of concept
#63Earlier quoted context omitted.
Postgres is currently the most advanced RDMS, anyone who's not locked in by Oracle or whatever and doesn't use Postgres for new projects is likely misinformed. Postgres essentially made every other RDMS obsolete except for some niche circumstantial cases (e.g. vendor lock-in) > enterprise level Postgres is enterprise level (whatever that means). Blazingly fast, Web 3, cloud-native, etc etc, pick your own buzzwords
The same applies to those that think Postgres does everything, every single feature, that Oracle, SQL Server, DB 2, and co, are able to deliver, in projects where their license costs are kind of irrelevant in the big context of the organization. Usually, it is a great way for many organizations to have a database as free beer.
And on the very uncommon cases that you need really something that Postgres doesn't do, Oracle, MS SQL, DB2, and co do not provide enough of a difference, and what you actually need is an specialized DBMS.
Re: Prolog language for PostgreSQL proof of concept
#64Earlier quoted context omitted.
Sure, a few organizations may actually need some obscure feature that Oracle provides, but again, it's niche. For most companies, Postgres provides way more features than they will ever use. And for the other 1%, it sometimes happens that their need for a specific feature in Oracle DB turns out to be entirely unnecessary. Not to mention that the vast majority of products turn out to be fancy CRUD apps. Doesn't matter…
There’s one thing Postgres doesn’t provide. It doesn’t provide a supplier who a company can put their liability on. A supplier who can fix the problem in Postgres code and maintain it with authority. But don’t get me wrong. Postgres is an awesome database system.
Potsgres is the one general purpose DBMS out there that you can hire a company to actually solve your problems.
Re: Prolog language for PostgreSQL proof of concept
#65Earlier quoted context omitted.
I wrote SQL queries twice that long for credit originations reports in banks which would hit several terabytes of disk read per run
Apologies, I should've been more clear. The absolute length of SQL wasn't what I was alluding to: it was the ratio of Datalog to SQL I was curious about based on this statement in the website: > Among database theoreticians Datalog and SQL are known to be equivalent. And indeed the conversion from Datalog to SQL and back is often straightforward. I was skeptical, and indeed the sample I linked to shows 8 lines of Dat…
CREATE TABLE edges (
source INT,
target INT
);
INSERT INTO edges (source, target)
SELECT generate_series as source, generate_series + 1 as target
FROM generate_series(0, 999);
WITH RECURSIVE path_lengths AS (
-- Base case: Direct paths from edges
SELECT source, target, 1 AS distance
FROM edges
UNION ALL
-- Recursive step: Double the path length by joining on intermediate nodes
SELECT p.source, e.target, p.distance + 1 AS distance
FROM path_lengths AS p
JOIN edges AS e ON p.target = e.source
WHERE p.distance
You can confirm the output matches by pasting it and clicking run here: https://extendsclass.com/postgresql-online.htmlRe: Prolog language for PostgreSQL proof of concept
#66Earlier quoted context omitted.
Prolog's evaluation semantics are order-dependent, though. I've always thought this was the reason why the two language paradigms didn't see more merging than they did. There are some datalog+RDBMS hybrids but, as much as I'm not a fan of .NET, I think LINQ has seen the most success in this space.
What are you concerned about when using .NET?
Re: Prolog language for PostgreSQL proof of concept
#67Earlier quoted context omitted.
Prolog's evaluation semantics are order-dependent, though. I've always thought this was the reason why the two language paradigms didn't see more merging than they did. There are some datalog+RDBMS hybrids but, as much as I'm not a fan of .NET, I think LINQ has seen the most success in this space.
What are you concerned about when using .NET?
I will say, though, that the .NET authors did seem to learn some lessons from Java's worse API decisions and the .NET API is more uniform and reasonable overall.
Re: Prolog language for PostgreSQL proof of concept
#68Earlier quoted context omitted.
All enterprise level RDMS have similar capabilities, some of which are yet to come to Postgres.
Postgres is currently the most advanced RDMS, anyone who's not locked in by Oracle or whatever and doesn't use Postgres for new projects is likely misinformed. Postgres essentially made every other RDMS obsolete except for some niche circumstantial cases (e.g. vendor lock-in) > enterprise level Postgres is enterprise level (whatever that means). Blazingly fast, Web 3, cloud-native, etc etc, pick your own buzzwords
Performance monitoring is pretty much absent, all you have is pg_stat_statements and friends. So for any serious scale you need 3d party solution (or you're writing your own) straight away.
HA is complicated. Patroni is the best option now, but it's quite far from experience SQL Server or Oracle provide.
Optimizer is still quite a bit simpler than in SQL server/Oracle. One big thing that is missing for me is "adaptive" query processing (there's AQP extension, but it's not a part of distribution). Even basic adaptive features help a lot when optimizer is doing stupid things (I'm not gonna bring up query hints here :))
Re: Prolog language for PostgreSQL proof of concept
#69Earlier quoted context omitted.
Apologies, I should've been more clear. The absolute length of SQL wasn't what I was alluding to: it was the ratio of Datalog to SQL I was curious about based on this statement in the website: > Among database theoreticians Datalog and SQL are known to be equivalent. And indeed the conversion from Datalog to SQL and back is often straightforward. I was skeptical, and indeed the sample I linked to shows 8 lines of Dat…
CREATE TABLE edges ( source INT, target INT ); INSERT INTO edges (source, target) SELECT generate_series as source, generate_series + 1 as target FROM generate_series(0, 999); WITH RECURSIVE path_lengths AS ( -- Base case: Direct paths from edges SELECT source, target, 1 AS distance FROM edges UNION ALL -- Recursive step: Double the path length by joining on intermediate nodes SELECT p.source, e.target, p.distance +…