Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Add MOC vs. other geometries casts#6

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
vitcpp merged 6 commits intopostgrespro:masterfrommsdemlei:add-moc-casts
May 24, 2023

Conversation

@msdemlei
Copy link
Contributor

This PR will enable search conditions such as scircle <@ moc. It is implemented as syntactic sugar, turning this, in effect, into smoc(max_order(moc), scircle) <@ moc.

While this has several drawbacks against a strict implementation of contains and overlap between spherical geometries and mocs – most notably, it will be a lot slower when comparing a constant geometry against moc-valued columns, because the conversion will be re-done in every row –, implementing these exact operations is at least hard.

For casual users, I argue, this will provide non-surprising behaviour.

This PR also bumps the version to 1.2.1. Piggyback on it rides a brief hacking guide I came up with while writing this.

in contains and intersects constraints.I'm also adding a little file on how to hack pg_sphere; yes, that'smainly repeating stuff from the pg docs, but I guess it'll helpa few folks; it would have helped me.
I hadn't done this before because the warnings spoiled the regressionexpectation.  I'm now shutting those up for while I'm doing the dropping.
@msdemlei
Copy link
ContributorAuthor

Can I bump this? The CI failures, I think, are unrelated to the PR, as pgsphere probably doesn't work with 9.x anyway (or does it? And if so, is there a strong case to not drop 9.x support?).

I give you this isn't perfect and rather certainly won't be terribly fast, but then itwill help for tables in the ~1e4 rows range, such as rr.stc_spatial in future RegTAP (the VO registry discovery protocol,https://github.com/ivoa-std/RegTAP).

jesse-savary reacted with thumbs up emoji

@msdemlei
Copy link
ContributorAuthor

Since it'd be great to have these operators for RegTAP 1.2,https://ivoa.net/documents/RegTAP/20220519/, can I nag again about this? I realise we'll not win beauty contests with this, but I'd say it's reasonably harmless and cheap while giving a rather real benefit...

Copy link

@gmantelegmantele left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

It seems all right to me.
It passes all CI for Postgres 10 and more.

@vitcppvitcpp self-assigned thisMay 24, 2023
@vitcppvitcpp merged commit432b098 intopostgrespro:masterMay 24, 2023
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

1 more reviewer

@gmantelegmantelegmantele approved these changes

Reviewers whose approvals may not affect merge requirements

Assignees

@vitcppvitcpp

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@msdemlei@gmantele@vitcpp

[8]ページ先頭

©2009-2025 Movatter.jp