Live data from Hacker News

Prolog language for PostgreSQL proof of concept

github.com

21–30 of 83 posts

Re: Prolog language for PostgreSQL proof of concept

#21
post #16

Postgres is not just a relational db. It's a way of life. JSONB, HSTORE, LTREE, Full Text Search, Logical Replication, Range Types, BRIN Indexes, GIN Indexes, GiST Indexes, SP-GiST Indexes, Table Inheritance, Foreign Data Wrappers, XML Support, UUID-OSSP, pg_trgm, Cube, Earthdistance, pg_prolog, pg_partman, pgvector, TimescaleDB, PostGIS, Citus, pg_cron, BDR (Bi-Directional Replication), PL/Python, PL/Java, PL/V8, pg…

All enterprise level RDMS have similar capabilities, some of which are yet to come to Postgres.

Re: Prolog language for PostgreSQL proof of concept

#22
When I saw the title I hopes this would be schema aware. Looking into the current proof of concept they allow to write prolog definitions.

How cool would be be, if all relations in a Postgres database would be lifted into the scope of a prolog process to work directly on the relations.

Re: Prolog language for PostgreSQL proof of concept

#24
post #15

Love this, I've long considered that this should've been made as Prolog and SQL are ternary logic and basically SQL derives from Datalog and it itself from Prolog. A table record can be taught as of as a Prolog fact, so this makes the WHERE clauses the predicates in the conjunction on the right-hand side of a rule. And then exhausting the goal is actually returning the result-set. Hope to see this develop even furthe…

[flagged]

Re: Prolog language for PostgreSQL proof of concept

#25
post #16

Postgres is not just a relational db. It's a way of life. JSONB, HSTORE, LTREE, Full Text Search, Logical Replication, Range Types, BRIN Indexes, GIN Indexes, GiST Indexes, SP-GiST Indexes, Table Inheritance, Foreign Data Wrappers, XML Support, UUID-OSSP, pg_trgm, Cube, Earthdistance, pg_prolog, pg_partman, pgvector, TimescaleDB, PostGIS, Citus, pg_cron, BDR (Bi-Directional Replication), PL/Python, PL/Java, PL/V8, pg…

https://pigsty.io/blog/pg/pg-eat-db-world/

Re: Prolog language for PostgreSQL proof of concept

#26
post #21
post #16

Postgres is not just a relational db. It's a way of life. JSONB, HSTORE, LTREE, Full Text Search, Logical Replication, Range Types, BRIN Indexes, GIN Indexes, GiST Indexes, SP-GiST Indexes, Table Inheritance, Foreign Data Wrappers, XML Support, UUID-OSSP, pg_trgm, Cube, Earthdistance, pg_prolog, pg_partman, pgvector, TimescaleDB, PostGIS, Citus, pg_cron, BDR (Bi-Directional Replication), PL/Python, PL/Java, PL/V8, pg…

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

Re: Prolog language for PostgreSQL proof of concept

#27
post #18

Earlier quoted context omitted.

Oh nice, this is the one "SQL replacement" I'd actually look into

What puts you off prequel? https://prql-lang.org really readable, nice syntax imo

PRQL has some very nice features, but the syntax also has some not so nice features that you don't see in the examples. There's special parsing rules for parenthesis and newlines, and a special word wrap character is needed at times to disable the rule that treats newlines as the pipe operator.

Re: Prolog language for PostgreSQL proof of concept

#28
post #21

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

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.

Re: Prolog language for PostgreSQL proof of concept

#29
post #28

Earlier 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.

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 though, Oracle will convince you that you NEED their DB regardless.

Re: Prolog language for PostgreSQL proof of concept

#30

When I saw the title I hopes this would be schema aware. Looking into the current proof of concept they allow to write prolog definitions. How cool would be be, if all relations in a Postgres database would be lifted into the scope of a prolog process to work directly on the relations.

If your entire database can be lifted into the application's heap, it's probably small enough that I wonder why you've got it stored in an RDBMS... and because Prolog is lexically sensitive (order of sentences and the order of clauses in the sentence affect the eval result) then you would need to effectively load all related DB entries -- or maybe some cursor tricks to load domain entries lazily and the many small queries that entails.

What I've usually seen instead is starting from Datalog (declarative, order-independent) instead of Prolog, and converting that into the relevant SQL queries then loading the results into variables within the datalog context. This splits the knowledge base into IDB and EDB parts.

Post reply on HN