If you already know, Orafce is an extension that emulates in PostgreSQL, a subset of functions and packages from the Oracle RDBMS.

This extension is very helpful while porting Oracle applications to PostgreSQL, avoiding application code rewrites in a performant way.

Do you think it is worth having a similar emulation of Oracle functions/packages on Snowflake and BigQuery ?

Comments URL: https://news.ycombinator.com/item?id=46283009

Points: 1

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=45765086

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=45747605

Points: 15

# Comments: 18

Our applications and databases must have ultra high availability. It can be achieved with applications and data platforms hosted on different regions for failover.

Critical businesses should also plan for replication across multiple cloud platforms. You may use some of the existing solutions out there that can help with such implementations for data platforms.

- Qlik replicate - HexaRocket

and some more.

Or rather implement native replication solutions available with data platforms.

I am working on the world's first end-to-end Database Migration tool, supporting Oracle to PostgreSQL and MSSQL to PostgreSQL database migrations with AI for Schema Migrations. Until now, people used different tools for Schema Migration and Data Migration/Replication. During this process, we ended up building a data migration and replication tool supporting any databases between Oracle, SQL Server (MSSQL) and PostgreSQL databases.

Comments URL: https://news.ycombinator.com/item?id=40699572

Points: 2

# Comments: 11

For some applications it might be of great use but for a vast and complex applications architecture, the libyear metric might only oversimplify the complexity of dependency management,compatibility issues, updates and security patches, etc

I noticed that it focuses only on the age of dependencies without considering other factors like the how critical is the update, and how stable it is, and the improvements in newer versions, etc.

Also, on handling HTTP errors in activities by raising an "ApplicationError" based on the status code, might simplifies error handling but might need to see how it accounts for more complex scenarios where errors are transient or where a retry could be successful even for some client errors like rate limiting or temporary unavailability etc.

As the asyncio library itself does have a steep learning curve, integration of asyncio with workflow systems like Temporal that also uses Pythons native asynchronous features, developers should be careful about indirect or subtle bugs, especially in error handling and task management.

Comments URL: https://news.ycombinator.com/item?id=40267803

Points: 2

# Comments: 1

People laughed assuming that a smart phone is of no use and people prefer a PC or a laptop. Everything else is history.

What is important at all times is the timing and Identifying something that can change the world at the right time.

This is where the Top Leadership roles come into play. Identify the gaps and introduce the immediate action plan to make the best of the best.

Given current technology and what advancements are needed to make Unlearning more possible, probably there should be a time-to-unlearn kind of an acceptable agreement that allows organizations to retrain or tune the response that does not involve any response from the to-be-unlearned copyright content.

Ultimately, legal acceptance for unlearning may be all about deleting the data set that is part of any kind of violations from the training data set. It may be very challenging to otherwise prove legally through the proposed unlearning techniques, that the model does not produce any type of response involving the private data.

The actual data set contains the private data violating privacy or copyright, and the model is trained on it, period. This means, it must involve retraining by deleting the documents/data to be unlearned.

- Postgres documentation is one of the well maintained database documentations. This also means that developers, committers ensure changes to documentations for every relevant patch.

- talk about bugs in postgres compared to MySQl or Oracle or etc databases. Bugs are comparatively lesser or generally rare even if you are supporting postgres services as a vendor with lots of customers. the reason is the efforts involved by a strong team of developers in not accepting anything and everything, there are strict best practices, reviews, discussions, tests, and a lot more that makes it difficult for a patch or a feature to make it to a release.

- ultimately, more easy is the acceptance of a patch, more the number of bugs.

I love Postgres the way it is today and it still is the dbms of the year and developers most loved database.

I wish we have more Contributors, committers, developers and also users and companies supporting Postgres so that the time to push a feature gets more faster and reasonably easier with more support.