Re: How to implent CONVERT ( data_type [ ( length ) ] , expression ) function in postgreSQL
От | Tom Lane |
---|---|
Тема | Re: How to implent CONVERT ( data_type [ ( length ) ] , expression ) function in postgreSQL |
Дата | |
Msg-id | 32443.1414945719@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: How to implent CONVERT ( data_type [ ( length ) ] , expression ) function in postgreSQL (rohtodeveloper <rohtodeveloper@outlook.com>) |
Список | pgsql-hackers |
rohtodeveloper <rohtodeveloper@outlook.com> writes: > I need the convert function because that Our application will be switched from SQL Server to PostgreSQL. >> For the options you suggested: >> 1) Pass in datatype as string and deparse and process in the function. >> 2) Are you referring to pg_convert here? > 1) is yes. but I want to use the CONVERT ( data_type [ ( length ) ] , expression ) just as same as in the SQLServer, SO,that doesn't work.2) I mean modifying the 'src\backend\parser\gram.y' file. There will be a grammer conflict withthe PostgreSQL self's convert(data,src_encoding_name,dest_encoding_name) function. So what? Presumably your SQL-Server-based app doesn't use that function. You could probably make it work anyway by introducing two new productions, one that implements the CAST-equivalent syntax and one that defines extract() with a regular func_arg_list argument list. But I'm not sure I see the point if you're building a private fork. On the whole I agree with the other commenters suggesting that fixing your app to use SQL-standard syntax would be a better answer in the long run. It's quite unlikely that you're going to be able to hack Postgres to be bug-compatible with SQL Server in every last respect, so trying to run your app totally unmodified from its present state seems like a fool's errand. Anyplace where you can dodge the problem by switching to spec-mandated syntax that both DBMSes understand, you're way ahead of the game if you fix it that way. regards, tom lane
В списке pgsql-hackers по дате отправления: