Activity for Niels Kristian
-
Niels Kristian posted a comment on ticket #23
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 :-)
-
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:...
-
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.
-
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...
-
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!
-
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!
-
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!
-
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!
-
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!
-
One more. I can see the same applies to arrays. I have a column of CREATE TABLE da.customers ( id serial NOT NULL, created_at timestamp without time zone, items character varying[] DEFAULT '{}'::character varying[] CONSTRAINT customers_pkey PRIMARY KEY (id) ) The produced SQL looks like Insert into da.customers(id, created_at, items) Select * From (values (920, to_timestamp('2017-10-05 12.48.39.865186', 'YYYY-MM-DD HH24.MI.SS.US')'{first_item}')) as Q(id, created_at, items) Where not exists (Select...
-
WOW! That was unexpected fast! You are amazing. Yes it solves the issue, however now I see the same problem as with JSON but with HSTORE column types. An example: CREATE TABLE da.bin_data ( id serial NOT NULL, data extensions.hstore, created_at timestamp without time zone NOT NULL, CONSTRAINT bin_data_pkey PRIMARY KEY (id) ) Will produce: Insert into da.bin_data(id, data, created_at) Select * From (values (278116, '"weight"=>"800", "rating"=>"0"', to_timestamp('2013-11-05 18.08.27.802369', 'YYYY-MM-DD...
-
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!
-
One more. I can see the same applies to arrays. I have a column of items character varying[] DEFAULT '{}'::character varying[] The produced SQL looks like Insert into da.customers(id, created_at, items) Select * From (values (920, to_timestamp('2017-10-05 12.48.39.865186', 'YYYY-MM-DD HH24.MI.SS.US')'{first_item}')) as Q(id, created_at, items) Where not exists (Select * from da.customers T Where T.id=Q.id); missing the ::character varying[]
-
Ah, didn't think of that, that's a clever move!
-
WOW! That was unexpected fast! You are amazing. Yes it solves the issue, however now I see the same problem as with JSON but with HSTORE column types. An example: CREATE TABLE da.bin_data ( id serial NOT NULL, data extensions.hstore, created_at timestamp without time zone NOT NULL, CONSTRAINT bilviden_data_pkey PRIMARY KEY (id) ) Will produce: Insert into da.bin_data(id, data, created_at) Select * From (values (278116, '"weight"=>"800", "rating"=>"0"', to_timestamp('2013-11-05 18.08.27.802369', 'YYYY-MM-DD...
-
Add LIMIT option along side the WHERE option
-
Bugs when exporting timestamps and JSON
-
java version "1.8.0_05" Java(TM) SE Runtime Environment (build 1.8.0_05-b13) Java...
-
I'm having the same problem when connecting to a Postgresql database on OS X. Note...
1
