avi_vallarapu

This is probably an Interesting if not a Poll leading to interesting conversations.

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 ?

Well, I think someone just read the last paragraph and calling it an Ad :)

This is the reason why it is important to plan Disaster recovery and also plan Multi-Cloud architectures.

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.

https://www.hexarocket.com/

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.

I mean a mobile app for Android and Apple

Someone said GPT-4o can replace a Tutor or a Teacher in Schools. Well, that's way too far.

https://www.postgresql.org/about/news/postgresql-163-157-141...

I went through this project before.

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.

Relying on external APIs or databases within activities might lead to variability in workflow execution.

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.

It will be interesting to see it supporting AWS RDS and other DBaaS platforms for PostgreSQL, that are not Postgres derived databases.

It is probably an observation and a forecast at the right time. I remember my days at one of the Top Home and Enterprise PC manufacturing companies over 15 years ago, when there was criticism around Smart phones.

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.

No technology can guarantee 100% unlearning, and the only 100% guarantee is when the data is deleted before the model is retrained. Legally, even 99.99% accuracy may not be acceptable, but, only 100%.

Exactly, I think is where it leads to eventually. And that is what I my original comment meant as well. "Delete it" rather than using some more techniques to "unlearn it", unless you claim the unlearning is 100% accurate.

We need to consider the practicality of unlearning methods in real-world applications and the legal acceptance of the same.

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.

I posted my thought on another thread too : https://news.ycombinator.com/item?id=40231332

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

Theoretically this sounds great. I would worry about scalability issues with the Bayesian learning models practical implementation when dealing with the vast parameter space and data requirements of state of the-art models like GPT-3 and beyond.

Would love to see practical implementations on large-scale datasets and in varied contexts. I Liked the use of Dirichlet distributions to approximate any prior over multinomial distributions.

there is possibly a need for more unified standard across different implementations particularly from a software development and API design perspective.

During parsing and manipulation of JSON data, the syntactical discrepancies/behaviours between various libraries might need a common specification, for interoperability.

features like type-aware queries or schema validation, may be very helpful.

A few things to note

- 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. Nugs are comparatively lesser or generally rare even if you are supporting postgres services as a vendor with lots of customer. 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 to pass 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 reasonable easier with more support.

Is this a coincidemnce ? Or a pattern leading to an outlier ?

GitHub : https://github.com/HexaCluster/pgdsat

Inviting Contributors and Users to try

As already expected, PostgreSQL is the DBMS of the year 2023 https://db-engines.com/en/blog_post/106

This is incredible to see its popularity only growing.

It is a simple use case, but it can extended to more powerful AI chatbots

I believe that the great examples always arise from OpenSource projects. The design and modular code always play a great role in increasing the ability to customize or add features and also have an increase in collaboration from more volunteers. Developer life gets more interesting with a massively improved code quality when some tough decisions are taken much earlier.

Interesting to see the discussion going towards converting 66.9 cr to Millions.

However, what is the type of data is my curiosity. Is this sensitive data such as PCI or some details such as : Names, Phone Number, Location etc. If it is sensitive data, how he got that data is the biggest worry.

Hope there is enough clarity on the type of data.

Interesting to see where the world is moving towards.

Good luck with your tests. Nice article though.

And with search_path being set not only at GLOBAL level, but also at User and Session level is one of the advantage in Postgres.

The syntax : CREATE SYNONYM may not be available in Postgres while migrating from Oracle. But this does not mean that the feature is not possible in PostgreSQL. There are indeed better features upon leveraging search_path and VIEWS appropriately.

Indexes can be rebuilt ONLINE in PostgreSQL by default. Whereas in Oracle, it requires Enterprise Edition as the Standard or the Express Edition does not allow ONLINE Index rebuild.

Does this really require Oracle to only make it available under additional license ? Better to switch to Postgres

Well, the cost of outage vs the cost to maintain multiple ISP's is the key decision factor here.