-
Notifications
You must be signed in to change notification settings - Fork 225
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose PostgreSQL XML functions #7
Comments
…ew range operator methods for translation (e.g. client code can define and register a method that supports client evaluation). The goal is to build on CustomBinaryExpression and make it easier to add new operators (e.g. XML operators from issue #7). With the current structure, additional operator classes can be codified in 3 files: Npgsql{type_name}OperatorType, Npgsql{type_name}OperatorAttribute, and Npgsql{type_name}OperatorTranslator.
This has been around for a while. I'm going to take a run at for |
It's been around for a while, but it hasn't ever been requested by an actual user :) I suspect that with xml going out of fashion hardly anyone needs this... I'd suggest concentrating our efforts elsewhere until this gets some votes etc... |
Possibly relevant: |
@roji Is there a way to access postgres XML functionality before this is implemented ? |
From @roji on September 8, 2015 8:4
PostgreSQL supports xpath matching, which we can expose to the user when corresponding methods are used in the LINQ query. This would prevent the entire resultset from being pulled in to the client.
It may be a good idea to provide an opt-out for this in case there's trouble or client-side evaluation is preferred. At the query and model levels.
Copied from original issue: npgsql/npgsql#773
The text was updated successfully, but these errors were encountered: