11–20 of 46 posts
This is long overdue and elegantly done. Great work! On a personal note, it's great to finally see Neon & Supabase playing with each other. Much more interesting to me than Hasura.
PG community had a similar patch, which got reverted from PG 15 on the last minute: https://www.depesz.com/2022/04/06/waiting-for-postgresql-15-...
PG community had a similar patch, which got reverted from PG 15 on the last minute: https://www.depesz.com/2022/04/06/waiting-for-postgresql-15-...
this would be our preference. we'll try to support this for the next commitfest, and if it gets merged then we will deprecate our extension in favour of the native solution.
This years feature freeze will be on April 8th (https://www.postgresql.org/message-id/flat/9fbe60ec-fd1b-6ee...), so if it does not get committed within the next two and a half weeks it will miss this years Postgres release in September...
Earlier quoted context omitted.
this would be our preference. we'll try to support this for the next commitfest, and if it gets merged then we will deprecate our extension in favour of the native solution.
Is there a chance it gets committed during the current commitfest? See https://commitfest.postgresql.org/42/4086/ This years feature freeze will be on April 8th ( https://www.postgresql.org/message-id/flat/9fbe60ec-fd1b-6ee... ), so if it does not get committed within the next two and a half weeks it will miss this years Postgres release in September...
Earlier quoted context omitted.
Is there a chance it gets committed during the current commitfest? See https://commitfest.postgresql.org/42/4086/ This years feature freeze will be on April 8th ( https://www.postgresql.org/message-id/flat/9fbe60ec-fd1b-6ee... ), so if it does not get committed within the next two and a half weeks it will miss this years Postgres release in September...
I'll flag it with the team this week. I'm not sure what the blocker was previously, but it might just be a matter of submitting the patch again (with minor changes) so that it's "in" for commitfest, with someone willing to own the work over the next few months.
I am a bit worried, even though the patches seem to be "stable", they will miss the deadline... (since I would need those features as well)
Earlier quoted context omitted.
Hasura is also FOSS
Hasura is open core. Given the massive price increase they just did for their hosted version, I’d expect more and more future features will not land in core at all, to push people to pay.
I was also concerned with people reporting memory consumption/leak issues, as I’m planning to have lots of subscriptions. I don’t know haskell well enough, but from the outside it does match the symptoms of having dug themselves into an architectural complexity hole, which I assume is much harder to navigate with unorthodox tooling and practices.
Im still rooting for hasura, I like their way of making things dumb, simple and without too much technophilia for its own sake. They genuinely want you to focus on your business problems instead of blasting you with novel and overengineered concepts, like others do.
So how do you apply this in the real world when dealing with schema versions and database migrations?
Earlier quoted context omitted.
I'll flag it with the team this week. I'm not sure what the blocker was previously, but it might just be a matter of submitting the patch again (with minor changes) so that it's "in" for commitfest, with someone willing to own the work over the next few months.
I think the things that needed to be fixed from last year are already committed (more general stuff not directly related to the JSON patches). Also according to this message at least partial stuff from the JSON patches should be committed "...in the next few days..." however that was two weeks ago: https://www.postgresql.org/message-id/454db29b-7d81-c97a-bc1... I am a bit worried, even though the patches seem to be "…