Re: How to implent CONVERT ( data_type [ ( length ) ] , expression ) function in postgreSQL

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: rohtodeveloper <rohtodeveloper(at)outlook(dot)com>
Cc: Atri Sharma <atri(dot)jiit(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: How to implent CONVERT ( data_type [ ( length ) ] , expression ) function in postgreSQL
Date: 2014-11-02 16:28:39
Message-ID: 32443.1414945719@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

rohtodeveloper <rohtodeveloper(at)outlook(dot)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 with the 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-11-02 16:36:21 Re: how to handle missing "prove"
Previous Message Andrew Dunstan 2014-11-02 15:07:39 Re: Let's drop two obsolete features which are bear-traps for novices