Re: BUG #1947: Enhancement Request - CONCAT() function

So the argument boils down to we should add concat as a function because
Oracle runs on on EBCDIC and recommends not using concat and because
MySQL has no clue when it comes to SQL standards. Pretty distasteful
arguments, IMHO. Unlike some, I'm in favor of making it easy for people
to migrate from MySQL, but even I don't like the idea of cluttering up
the base functions because of their lack of clue.

As I said before, I think this is best left to http://pgfoundry.org,
unless it's impossible to create a function that accepts an arbitrary
number of arguments. If that's the case, I would argue for changing the
backend so user functions could have an arbitrary number of arguments,
and then creating a concat() project on pgFoundry.

On Mon, Oct 10, 2005 at 10:04:25PM +0100, Tony Marston wrote:
> No, but Oracle does, which is why I am trying to produce SQL statements that
> will run on MySQL, PostgreSQL and Oracle without the need for conversion.
>
> Tony Marston
>
> http://www.tonymarston.net
>
>
>
> > -----Original Message-----
> > From: Jim C. Nasby [mailto:jnasby@pervasive.com]
> > Sent: 10 October 2005 18:19
> > To: tony@marston-home.demon.co.uk
> > Cc: Bruce Momjian; 'David Fetter'; pgsql-bugs@postgresql.org
> > Subject: Re: [BUGS] BUG #1947: Enhancement Request - CONCAT() function
> >
> >
> > PostgreSQL runs on machines that use EBCDIC?
> >
> > On Mon, Oct 10, 2005 at 04:26:15PM +0100,
> > tony@marston-home.demon.co.uk wrote:
> > > Here is a direct quote from the ORACLE manual:
> > >
> > > <quote>
> > > On most platforms, the concatenation operator is two solid vertical
> > > bars, as shown in Table 3-3. However, some IBM platforms use broken
> > > vertical bars for this operator. When moving SQL script
> > files between
> > > systems having different character sets, such as between ASCII and
> > > EBCDIC, vertical bars might not be translated into the vertical bar
> > > required by the target Oracle environment. Oracle provides
> > the CONCAT
> > > character function as an alternative to the vertical bar
> > operator for
> > > cases when it is difficult or impossible to control translation
> > > performed by operating system or network utilities. Use
> > this function
> > > in applications that will be moved between environments
> > with differing
> > > character sets. </quote>
> > >
> > > Tony Marston
> > > http://www.tonymarston.net
> > >
> > > pgman@candle.pha.pa.us wrote:
> > > > Tony Marston wrote:
> > > > > > which Oracle supports and MySQL can be made to support via a
> > > > > > runtime option.
> > > > >
> > > > > They also both support CONCAT() because there are sometimes
> > > > > difficulties in dealing with vertical bars in the
> > character sets
> > > > > used by certain operating systems and file systems. If enough
> > > > > database vendors offer it then it becmes a "de facto" standard.
> > > >
> > > > I have never heard of problems with vertical bars in any of those
> > > > settings.  Can you elaborate?  I don't see how operating
> > systems and
> > > > file system character sets relate to SQL query characters.
> > > >
> > > > --
> > > >   Bruce Momjian                        |  http://candle.pha.pa.us
> > > >   pgman@candle.pha.pa.us               |  (610) 359-1001
> > > >   +  If your life is a hard drive,     |  13 Roberts Road
> > > >   +  Christ can be your backup.        |  Newtown Square,
> > Pennsylvania 19073
> > > >
> > >
> > >
> > > ---------------------------(end of
> > > broadcast)---------------------------
> > > TIP 5: don't forget to increase your free space map settings
> > >
> >
> > --
> > Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
> > Pervasive Software      http://pervasive.com    work: 512-231-6117
> > vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461
> >
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>

--
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461