Re: MySQL search query is not executing in Postgres DB

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Jeff Davis <pgsql(at)j-davis(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Stark <stark(at)mit(dot)edu>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, premanand <kottiprem(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: MySQL search query is not executing in Postgres DB
Date: 2012-11-27 17:07:54
Message-ID: CAHyXU0w1d-3Mbu2sU6v4neywJ5ntW3ATV6r6-4N4vLgMBNRYEQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 27, 2012 at 10:52 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
> it is a basic problem - PostgreSQL has unique possibilities -
> polymorphic parameters and almost all databases doesn't support
> overloading

Speaking of polymorphism, why not just implement lpad()'s first
argument as 'anyelement'? ISTM this comes up in mostly in porting
code from other database that is utilizing standard sql functions.
This should be appropriate when the function's basic functionality and
argument signature is not dependent on input type (constrast:
to_timestamp) and there is a good portability case to be made.
Essentially, this applies to a handful of string processing routines
AFAICT.

merlin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-11-27 17:11:44 Re: Re: Problem Observed in behavior of Create Index Concurrently and Hot Update
Previous Message Tom Lane 2012-11-27 17:02:09 Re: Re: Problem Observed in behavior of Create Index Concurrently and Hot Update