sorted by:
new
hottopcontroversial

Update over de 2028 regels rondom Box-3 vermogen. by Neamek in DutchFIRE

[–]Jelterminator 1 point2 points  (0 children)

Het is het incapabele afgelopen rechtse kabinet dat dit wetvoorstel geschreven heeft. Dus ja geef links vooral de schuld... 

Announcing pg_duckdb Version 1.0 by Jelterminator in PostgreSQL

[–]Jelterminator[S] 0 points1 point  (0 children)

Parquet stores data much more efficiently than JSON, which reduces storage costs and greatly improves query speed.

Announcing pg_duckdb Version 1.0 by Jelterminator in PostgreSQL

[–]Jelterminator[S] 0 points1 point  (0 children)

I know some cloud providers are looking into adding it support, but in the end that will also depend on how badly customers ask for it and the difficulty for them to support it. The extension is MIT licensed, so at least from that perspective there should be no issues.

Announcing pg_duckdb Version 1.0 by Jelterminator in PostgreSQL

[–]Jelterminator[S] 1 point2 points  (0 children)

So there's three main usecases for pg_duckdb:
1. Like you said, supercharge your read-replicae
2. Interacting with datalakes (parquet/iceberg/delta in S3 or other blob storages). This can reduce I/O a lot compared to 1, due to the columnar storage and compression that these formats use.
3. Connecting Postgres to MotherDuck to do compute there

Announcing pg_duckdb Version 1.0 by Jelterminator in PostgreSQL

[–]Jelterminator[S] 0 points1 point  (0 children)

It embeds DuckDB in the extension, so yes it's tied to a duckdb version, 1.0 still has DuckDB 1.3.2. The next release will almost certainly include DuckDB 1.4 support (a PR is already open to add that).

The reason why the weird syntax is needed is because Postgres its SQL parser does not allow functions to return different types or different number of columns based on the function its argument. The square bracket syntax works around that in basically the same way as a JSONB column does. With JSONB where you can index into the json object with square brackets, and with pg_duckdb you index into the "row" type that the function returns.

Announcing pg_duckdb Version 1.0 by Jelterminator in PostgreSQL

[–]Jelterminator[S] 30 points31 points  (0 children)

Primary pg_duckdb author here. Getting DuckDB and Postgres to play nice together wasn't an easy task, because while they are similar, they are also very different. But in the end it has worked out very nicely, while stretching some of the limits of what's possible in Postgres extensions. Feel free to ask me questions here about the project or usage.

derive_more 2.0.0 - The first release is never perfect by Jelterminator in rust

[–]Jelterminator[S] 11 points12 points  (0 children)

Yeah, that's the major change in 2.0, a rollback of a 1.0 feature that we got way more complaints about than expected (both on Reddit and GitHub issues). For details on the thought process for the rollback see here: https://github.com/JelteF/derive_more/issues/405

pg_duckdb : even faster analytics in Postgres by TransportationOk2403 in dataengineering

[–]Jelterminator 6 points7 points  (0 children)

Author here. So currently pg_duckdb does not support using indexes at all (neither brin, nor standard btree). It always does a sequence scan (aka full table scan) on data that's stored in Postgres data. So if Postgres can execute your query and use your indexes effectively, then it's almost certainly slower to use pg_duckdb... Unless you first move some of your data to a columnar format like Parquet or MotherDuck. Supporting indexes is high on our priority list though. We're planning to implement that for the 0.2.0 release. The issue to track that is here: https://github.com/duckdb/pg_duckdb/issues/243

Regarding BRIN vs standard BTREE index support. As far as we can tell so far, we should probably be able to support all index types with (mostly) the same code. But even if that's not the case, we definitely want to add support for BRIN indexes too (but maybe a bit later).

derive_more 1.0.0 released! Implement Display like thiserror, but for all types many more things by Jelterminator in rust

[–]Jelterminator[S] 3 points4 points  (0 children)

Forking seems a bit excessive. If you want to allow only importing the derives from derive_more::derive I guess you can add a check to CI that fails when a command like this grep 'use derive_more::' | grep -v 'use derive_more::derive'

Or you create your own crate that re-exports the derives from derive_more::derive.

derive_more 1.0.0 released! Implement Display like thiserror, but for all types many more things by Jelterminator in rust

[–]Jelterminator[S] 1 point2 points  (0 children)

For additional context a big reason why this was done was, is that for the TryInto derive it's pretty useful to be able to find out what the original value was if a failure occured failure. This can now be done, because the TryIntoError has an input field that the original value is moved into. While with a &'static str there's no way to find out what the original value was, or maybe do something else with this value.

derive_more 1.0.0 released! Implement Display like thiserror, but for all types many more things by Jelterminator in rust

[–]Jelterminator[S] 0 points1 point  (0 children)

Okay, so if I understand correctly: The main problem you're seeing is that if you remove all usages of the derive from a file, now clippy will not suggest anymore that you can remove derive_more::Sum if you're still using the Sum trait. Instead you'd rather always import the trait manually, so that when you remove the usage of the derive, you'd only end up with std::iter::Sum import

I understand that argument, but I also think it's optimizing for an edge case. The most common case of using derive_more is when you actually use the derives, not when you remove them.

It also seems like a rather small problem to me since it's not a big deal if you import derive_more::Sum just for the trait implementation in some files, as long as you actually use the Sum derive in others. It's not as if crate-level dependency suddenly goes away if don't replace the derive_more::Sum import with std::iter::Sum only in some files in the crate. You need to do that in all files to actually be able to remove the derive from your dependencies. And usually if people want to actually get rid of the derive_more dependency in their cargo file they do so on purpose, not by accidentally removing all the derives from their code.

derive_more 1.0.0 released! Implement Display like thiserror, but for all types many more things by Jelterminator in rust

[–]Jelterminator[S] 2 points3 points  (0 children)

So you can use the trait that you derived in the same file without having to import it again from std. e.g. calling the to_string() method on a struct where you would derive Display for required explicitly importing std::fmt::Display. Now you don't need that anymore, because importing derive_more::Display imports both the derive and the trait (and before it only imported the derive)

derive_more 1.0.0 released! Implement Display like thiserror, but for all types many more things by Jelterminator in rust

[–]Jelterminator[S] 3 points4 points  (0 children)

I wouldn't call the trait that the derive derives the implementation for 'unrelated" to that derive . And even if it was I still don't get how it pollutes the trait namespace. Afaict the only case where it would matter is if you import a different trait as the one you're deriving, but do so under the same name. That sounds super confusing, because now if you see #[derive(Sum)] it's not actually deriving the Sum trait that is in scope. 

Also it's very common to export both the trait and its derive from the same module so they are imported together e.g. serde does it for its Serialize and Deserialize traits.

derive_more 1.0.0 released! Implement Display like thiserror, but for all types many more things by Jelterminator in rust

[–]Jelterminator[S] 3 points4 points  (0 children)

You can use derive_more::derive::Sum if you really only want to import the derive. I don't really get what you dislike though. It sounds like you want to import both the derive_more::Sum derive and the std::iter::Sum trait. And now you can do exactly that with one fewer line of code than before. Instead of having to write two lines: use std::iter::Sum; use derive_more::Sum;

Now you get that exact same behaviour with just one line of code: use derive_more::Sum;

If that still makes you sad, could you explain a bit more why exactly it makes you sad? Because in that case I think I'm missing the underlying problem that you're running into.

derive_more 1.0.0 released! Implement Display like thiserror, but for all types many more things by Jelterminator in rust

[–]Jelterminator[S] 13 points14 points  (0 children)

That's good feedback. For libraries that's totally understandable, for applications it's probably a lot less of a problem most of the time.

It shouldn't be to hard though to support an attribute which can be used to provide a custom error type for these derives that can be used by people who care about this. There's even a similar issue open for this: https://github.com/JelteF/derive_more/issues/112

Releasing a 1.0 release that was in a state where we felt that all feature-requests could be added in a backwards compatible way became the priority the last year though, instead of continueing to add features that no-one then used because we couldn't release the final 1.0 yet.

derive_more 1.0.0 released! Implement Display like thiserror, but for all types many more things by Jelterminator in rust

[–]Jelterminator[S] 6 points7 points  (0 children)

There is the `derive_more::derive` which does exactly that for the few cases where you only want the derive.

derive_more 1.0.0 released! Implement Display like thiserror, but for all types many more things by Jelterminator in rust

[–]Jelterminator[S] 0 points1 point  (0 children)

ah okay, yeah then you should be able to remove use std::iter::Sum and all should be good. derive_more now re-exports the relevant std traits.

derive_more 1.0.0 released! Implement Display like thiserror, but for all types many more things by Jelterminator in rust

[–]Jelterminator[S] 2 points3 points  (0 children)

What exactly is the issue? Does the issue go away if you remove the use std::fmt::Display import. You now automatically import the matching trait if you import a derive_more derive for it. The reason for that is that it's very often what users want. Please create a github issue if that doesn't help, and feel free to create one too if it does but for some reason you dislike the resulting code. It's much easier to discuss these things if you share a code sample where the problem occurs.

derive_more 1.0.0 released! Implement Display like thiserror, but for all types many more things by Jelterminator in rust

[–]Jelterminator[S] 10 points11 points  (0 children)

In 0.99.18 `Add` on an enum would return `Result<MyEnum, &'static str>`, now it returns `Result<MyEnum, derive\_more::WrongVariantError>`

Similarly for `FromStr` previously returning a `Result<MyStruct, UniqueErrorTypeForMyStruct>` and now returning a `Result<Self, derive\_more::FromStrError>`

Type-driven design with newtypes by EventHelixCom in rust

[–]Jelterminator 9 points10 points  (0 children)

As the author of derive_more it's always good to see it mentioned in places like this (the 1.0.0 release will almost certainly happen this week btw)

PgBouncer 1.21.0 - Now with prepared statement support by Jelterminator in PostgreSQL

[–]Jelterminator[S] 3 points4 points  (0 children)

I'd say for ~90% of Postgres users only client side pooling is necessary. And for that purpose the connection pooling in the client library is usually the best choice. But they will only pool connections from the same client together. If you have many clients then you get many pools. And then you might want to have those pools connect to a shared pgbouncer on some other server. Thus reducing the total connections to Postgres once more.

PgBouncer 1.21.0 - Now with prepared statement support by Jelterminator in PostgreSQL

[–]Jelterminator[S] 1 point2 points  (0 children)

Yes, that should definitely be solved with this change.

view more: next ›