I am migrating a database with geometric data from MySQL to PostgreSQL. I've run into a snag because the POINT datatypes are incompatible between the two databases.
In MySQL, the POINT values are single hex strings like 0xE21D4B40. However, I cannot insert these into PostgreSQL because PostgreSQL's POINT datatype expects coordinates in the form of (x,y). What is the best way to handle this conversion?
#tadman's comment ended up being my solution: unpacking the hex string to a pair of values on the MySQL side. In my case the hex string was a column called location in the city table, so I used the query SELECT ST_AsText(location) FROM city;.
This returned rows like POINT(-133.03531 54.23346) which PostgreSQL was happy to accept.
Related
I am migrating a database from PostgresSql to MySql.
We were saving files in the database as PostgreSQL bytea columns. I wrote a script to export the bytea data and then insert the data into a new MySql database as a blob. The data is inserting into Mysql fine, but it is not working at the application level. However, the application should not care, as the data is exactly the same. I am not sure what is wrong, but I feel like it is some difference between MySql vs. PostgreSQL. Any help would be greatly appreciated.
This could really be a number of issues, but I can provide some tips in regards to converting binary data between sql vendors.
The first thing you need to be aware of is that each sql database vendor uses different escape characters. I suspect that your binary data export is using hex and you most likely have unwanted escape characters when you import to your new database.
I recently had to do this. The exported binary data was in hex and vendor specific escape characters were included.
In your new database, check if the text value of the binary data starts with an 'x' or unusual encoding. If it does you need to get rid of this. Since you already have the data inserting properly, to test, you can just write an sql script to remove any unwanted vendor specific escape characters from each imported binary data record in your new database. Finally, you may need to unhex each each new record.
So, something like this worked for me:
UPDATE my_example_table
SET my_blob_column = UNHEX(SUBSTRING(my_blob_column, 2, CHAR_LENGTH(my_blob_column)))
Note: The 2 in the SUBSTRING function is because the export script
was using hex and prepending '\x' as a vendor specific escape character.
I am not sure that will work for you, but it maybe worth a try.
I stored a field of records as JSON "[1,2,3,14,4]"
In MySQL 5.7, I used JSON_LENGTH to count it.
But How can I count in MySQL 5.5.
This is my example query in MySQL 5.7.
SELECT JSON_LENGTH(view_cnt) AS view_cnt FROM `tbl` WHERE `published`=1
Since mysql v5.5 does not have any json support, you need to get creative using string functions.
If your json is simple and does not have values that themselves contain comma, then just count then number of commas within your string and add 1 to it:
select char_length(json_field)-char_length(replace(json_field,',',''))+1 from table
If your json values contain commas, then you would have to write a json parser in mysql to get the length.
i have a insert statement pulling data from db link.
insert into table (a,b,c)
select a,b,c from table#mysqldb;
here column c is long type in mysql and in oracle its varchar
i tried to cast as varchar, substr(c, 1,2400), UTL_RAW.CAST_TO_VARCHAR2,dbms_lob.substr
none of them are working on oracle side.
tried cast on mysql read part no use.
Can someone tell me how to do this. Here Iam trying to convert long to varchar. we cannot load as clob as this table is used in many places and we cannot change things at so many places
Thanks.
i had to convert the target column to clob to handle this scenario
I am storing IPv6 addresses as a varbinary with PHP function inet_pton($_SERVER['REMOTE_ADDR']). When I run an SQL query such as:
SELECT ip_address FROM some_table WHERE id='some_id';
I wouldn't be able to read the ip_address because it is in a binary format.
I notice that there is a corresponding MySQL function INET6_NTOA(expr) in MySQL version 5.6 to revert it back to readable format. Unfortunately, I am using MySQL version 5.5, which doesn't have that function.
Is there any other way I can read the IPv6 addresses without going back to PHP to do the conversion? I can easily read off the hexadecimal notation of the binary string with the editor in the Workbench as shown in the image attached, so I thought there should be an easy way to do this.
You can write user-defined functions to do the conversion for you and call them in the select clause. See this link for more info.
I have this MySQL query, and it works on a MySQL database, but not on a PostgreSQL one:
select setype from _entity where id='72#78|'
Now, what exactly is '72#78|' trying to do? id is an integer field, so when the query is run on a Postgressql DB, it gives an invalid input syntax for integer: "72#78|" error.
I know that | is a bitwise OR operator, but what exactly is being ORED here? And, just as importantly, what is the # for? I tried to look for it in the MySQL manual, but due to sub-par searching skills, I couldn't find it.
When I run the above query on a MySQL DB, it finds data with an id value of 72,somehow, the expression evaluates to the first number.
So, what is the above query trying to do, and how do I convert it into a PostgreSQL equivalent?
Thanks for all your help, have a good day.
MySQL is converting the text string to a numeric, and ignoring anything after the first non-numeric character, therefore, it is just comparing id = 72, which is what you are getting from the output.
My guess is that PostgreSQL is trying to convert the whole string to an integer and failing because it isn't a valid integer value.
To do the equivalent in PostgreSQL, you would need to convert the 72#78| to a simple integer before running your query.