Npgsql is the .NET data provider for Postgresql. It allows any program developed for .NET framework to access a Postgresql database server. It is implemented in 100% C# code. Postgresql versions since 9.0 are officially supported, others may work.
Hello guys,
Could you look why some links on you site have been stop worked on the, i.e.
Could you look why some links on you site have been stop worked on the, i.e.
Hi @roji , we have run into this bug in production npgsql/npgsql#3469
can you advise when 5.0.3 will be released to nuget? We are debating wether to revert our upgrade to ef5/npqsql5 or wait for the patch. We can realistically wait no more than 24 hours before we have to revert so we can continue shipping features on our service
can you advise when 5.0.3 will be released to nuget? We are debating wether to revert our upgrade to ef5/npqsql5 or wait for the patch. We can realistically wait no more than 24 hours before we have to revert so we can continue shipping features on our service
hm, that sentence doesn't quite read right... we have deployed an old version of our microservice from before the upgrade to restore service. the revert is referring to the Pull Request we would need to revert internally to undo the net5 updates. Our preference would be to roll forward with the new drivers than undo it all and try agin later
I think nothing block us from release, but I would like to see npgsql/npgsql#3402 merged first. @roji ?
@sflusov you can find these under https://www.npgsql.org/doc/types/datetime.html etc. (go to the site root and navigate from there)
FYI I've release 5.0.3. It doesn't contain npgsql/npgsql#3402 as that issue still has some design issues/questions around it.
I am working on a POCO generator that reads Postgres DDL and generates .NET POCO. I see NpgSql's documentation defines the Postgres to .NET mapping. Is there a method or methods available in Npgsql where I could say "GetDotNetTypeForPostgresType(string postgresType)" and be returned a string of the mapped dotnet type?
FWIW: I did try to hunt through the source.. but I wasn't finding it.
Entity Framework can create pretty complex (blown-up) queries with many joins for LINQ-queries that requests data to be returned in something similar to a big json-structure. Those queries get quite complex resultset layout and due to the heavy use of joins data can easily be duplicated many times when sent over the wire. The json-functions in PostgreSQL can be used to return the data in a json-structure instead, which will be more on the form what the user wants, and hence not include any duplicate data. Can Entity Framework Core take advantage of this?
@Emill general JSON support is one of the specific themes being looked at for EF Core 6.0 - not just for PG (other databases also have good JSON capabilities). We've specifically discussed projecting data out of the database as a JSON document, it's indeed a very interesting direction. But right now nothing like that is supported. Note that EF also has split query mode, which mitigates a lot of the issues with many joins in a single query (https://docs.microsoft.com/en-us/ef/core/querying/single-split-queries)
I'd like to see an extension of jsonb that could be used with arbitrary postgresql data types
i.e. something like record and arrays
something like
select tbl1.*, array_agg(tbl2) from tbl1 left join tbl2 on tbl1.id = tbl2.tbl1_id group by tbl1.id can be used to list all tbl1 items including all tbl2 items belonging to a tbl1 item
Yeah, I've looked at array_agg, and also at making it work with EF Core: npgsql/efcore.pg#727, dotnet/efcore#22957
But you're right that the basic problem with this approach, is that a JSON document simply isn't typed in the same way as data coming back directly (in PG binary encoding, decoded by handlers). So handing off the JSON document directly to the user is one thing - it bypasses the ORM capability completely, and it's the user's responsibility to parse and create entity instances out of the JSON, if that's what they want.
Making EF Core actually materialize from JSON would be different, and probably quite problematic (e.g. do we just parse timestamp string representations? What about weirder types?)
My idea was that the user shouldn't need to explicitly ask for array_agg etc. but should be a strategy inside EF to avoid "cartesian explosion" and split query.
If json_agg turns out to be more efficient for some reason than array_agg and row(...), maybe that can be used instead if EF can validate that only text, integers etc. are included in the data to be returned.
It's definitely something that's there in the back of my mind
First EF Core would need to add general support for provider-specific aggregate methods though
In any case, there's no reason to supposed json_agg is better than array_agg - quite the opposite, since parsing the JSON and the textual representation of the values within is useless overhead
This is something that I hope to look at one day, once the provider-specific aggregate function support is done on the EF Core side (the issues above)
Though writing an EF materializer is not an easy thing to do :) Just look at the regular one...
I'm kind of left where EF 6 was at 5 years ago right now
BTW there's already a lot of interesting array support in the PG provider, where PG can do things far better than other databases
cool
In EF Core I could add all the special PG types
And the fact you can map an array/List property to PG arrays is quite powerful. Then you can do stuff like blog.SomeArrayProperty.Any(p => p > 3), which will translate into the correct PG construct and execute efficiently
With other databases you have to either have a comma-separated string column, or a one-to-many relationship...
If you like expression trees and the idea of translating constructs from C# to SQL, then EF Core is really fun to work on