User Activity

  • Posted a comment on ticket #23 on Jailer

    Thanks! It's all running perfectly now. I do not know of any other data types on top of my head. However I'm quite sure some exists. I did a bit of research but didn't find any for now. Thanks again for your swift response :-)

  • Posted a comment on ticket #23 on Jailer

    Hi again. Well all of them works. However the first option would require the user to himself make sure that the apropriate schemas are in the search_path of the current database session. So since the rest of the statements are selfdescribing including schemas, I guess the first is out of the question. The following two works both of them, however I think the second one ::"extensions"."hstore" is the more correct one, and it's also how the data type is listed in the columns.csv Running this works:...

  • Posted a comment on ticket #23 on Jailer

    Ahh I see! here you go: data "extensions"."hstore" null; created_at timestamp; Hmm yeah, that makes it tricky. I guess your code expects hstore to always be located in the same schema as the table, In that case, it will just say hstore instead. So I guess there is a need of supporting when hstore is installed into a different schema. To my knowledge, this is often the case.

  • Modified a comment on ticket #23 on Jailer

    The data type is hstore. The extensions.hstore is just because the hstore data type is added through a so called extension which needs to be installed into a specifc schema. You can add extensions to Postgresql for all kinds of functionality. In our contrete setup, the hstore-extension is installed in another schema we called extensions. This is a schema just like all other schemas. e.g. the shcema the table itself is created in which is called da. So in other words. don't mind the extensions.hstore...

  • Modified a comment on ticket #23 on Jailer

    The data type is hstore. The extensions.hstore is just because the hstore data type is a so called extension you can add to Postgresql, like many other functionalities. In our contrete setup, the hstore-extension is installed in another schema called extensions just like the table itself is created in the schema da. So in other words. don't mind the extensions.hstore part. As long as the ::hsotre data type is appended to the string (just like the ::json) everything is fine!

  • Modified a comment on ticket #23 on Jailer

    The data type is hstore. extensions.hstore is just because the hstore data type is a so called extension you can add to Postgresql, like many other functionalities. In our contrete setup, the hstore-extension is installed in another schema called extensions just like the table itself is created in the schema da. So in other words. don't mind the extensions.hstore part. As long as the ::hsotre data type is appended to the string (just like the ::json) everything is fine!

  • Modified a comment on ticket #23 on Jailer

    extensions.hstore is just because the hstore data type is a so called extension you can add to Postgresql, like many other functionalities. In our contrete setup, the hstore-extension is installed in another schema called extensions just like the table itself is created in the schema da. So in other words. don't mind the extensions.hstore part. As long as the ::hsotre data type is appended to the string (just like the ::json) everything is fine!

  • Modified a comment on ticket #23 on Jailer

    extensions.hstore is just because the hstore data type is a so called extension you can add to Postgresql, like many other functionalities. In our contrete setup, the hstore-extension is installed in another schema called extensionsjust like the table itself is created in the schema da. So in other words. don't mind the extensions.hstore part. As long as the ::hsotre data type is appended to the string (just like the ::json) everything is fine!

View All

Personal Data

Username:
nielskristian
Joined:
2013-02-15 11:14:59

Projects

  • No projects to display.

Personal Tools

MongoDB Logo MongoDB