-
Notifications
You must be signed in to change notification settings - Fork 412
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
Using geographic objects as properties with PostGIS #48
Comments
Sorry, about the late response, I had responded but, not to this thread. From my April 2nd response - When a function isn't prefaced with the schema in the cypher function call, the transform logic will see it as a cypher function and prepend age_ to the name and then add the schema ag_catalog. This avoids naming clashes and helps with understanding where the system is looking for something. So, if you want to use a specific PG or other user function, you need to specify the specific schema that it is in. When a schema is provided, the transform logic no longer looks for it in ag_catalog with a prepended age_. The function call transforms, inside the cypher function call, recurse through the arguments. So, nested calls will be processed by AGE in the above manner. This logic may, or may not change in the future. The issue here is that the PG routines that search for the function will exit if one is not found. So our code - unless we add in more of PG's code and modify it - will never get a second chance to process it for additional matches. So, we had to find a happy middle ground. Unfortunately, some of PG's errors are vague. Was it not found at all? or just not one that matches the arguments? Only the debugger can tell you. For this particular issue, this means that any non-AGE function needs its schema name added if it appears in the cypher function command. As an example, for PG's sqrt(4), it would be pg_catalog.sqrt(4). Additionally, any function argument inside the cypher function command will be transformed through AGE. These are not the same typecasts as PG's typecasts. So, typecasts like 4::float, will be translated as some number into agtype float, not PG's float. We plan on adding ones like ::pg_float shortly. There is currently an exception to this, and that is due to an implicit cast that is going to be removed and replaced by an explicit cast. There is an implicit cast to float, that will be removed shortly, so if everything is correctly named, what you have above should work - for items that can be cast to a float. As an example -
Hopefully this helps. Unfortunately, I am unable to get Postgis installed and therefore I can't debug it further at this time. |
As of the current release, the implicit cast to float has been removed. Additionally, casts have been added to cast an agtype value out to a PG type for the following types: bigint and float8 Examples:
|
I should note that for use with an indirection, it needs to be done this way -
Sorry for all the edits. |
Is there a way to add PostGis data as property to a node (e.g., a point geometry)?
I've tried:
Additional information: the indivial extensions (age, postgis) do work:
The text was updated successfully, but these errors were encountered: