"Prabakaran, Vaishnavi" writes:
> The specific use case which I am interested in is
> " Numeric LIKE Pattern_string ".
> I'm willing to attempt a patch to support the specific use case above by
> adding implicit casts, without modifying the entire casting rules.
> Is this something that is li
Josh Berkus; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Differences in WHERE clause of SELECT
Robert Haas wrote:
> We can certainly continue to play whack-a-mole and dream up a new
> solution every time a really intolerable variant of this problem comes
> up. But that doesn&
Robert Haas wrote:
> We can certainly continue to play whack-a-mole and dream up a new
> solution every time a really intolerable variant of this problem comes
> up. But that doesn't seem good to me. It means that every case
> behaves a little different from every other case, and the whole thin
On Tue, Jul 16, 2013 at 2:58 PM, Merlin Moncure wrote:
> On Tue, Jul 16, 2013 at 12:58 PM, Robert Haas wrote:
>> PostgreSQL requires more casts that any other mainstream database
>> system on the planet, and it's one of the biggest barriers to
>> migrating from other database systems to PostgreSQ
On Tue, Jul 16, 2013 at 12:58 PM, Robert Haas wrote:
> PostgreSQL requires more casts that any other mainstream database
> system on the planet, and it's one of the biggest barriers to
> migrating from other database systems to PostgreSQL. I understand
> that there is a consensus in this forum to
On Tue, Jul 16, 2013 at 12:05 PM, Tom Lane wrote:
> I don't agree with this opinion.
I know.
> '1' + '2' might be claimed to have
> only one plausible meaning as well, but that doesn't mean that we should
> accept it.
That example clearly has multiple sensible interpretations, because
surely we
On Tue, Jul 16, 2013 at 4:40 PM, Robert Haas wrote:
> But '1' LIKE 1 is not ambiguous
What about '1' LIKE 01 ?
What do people who write this actually expect LIKE to do? I gather
they're actually treating it as a synonym for =?
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers
Robert Haas writes:
> I continue to be of the opinion that our behavior in this area is
> bone-headed. It's reasonable to reject integer = character varying on
> the basis that we don't know whether integer or character varying
> comparison semantics are wanted, and the two might give different
>
On Tue, Jul 9, 2013 at 7:12 PM, Josh Berkus wrote:
> Like uses the operator class "text_pattern_ops" which doesn't include an
> implict cast.
This is wrong. Casts are associated with data types, not operator classes.
> For one thing, the implicit cast is from text -->
> integer, not the other w
On Wed, Jul 10, 2013 at 8:42 PM, Prabakaran, Vaishnavi
wrote:
> Hi Berkus,
>
> Thanks for your time and response.
>
> I do understand that there is no LIKE operator support for integers and it
> would be great if you could help me understand the reason why is it not
> supported.
>
> My intentio
On Wed, Jul 10, 2013 at 8:42 PM, Prabakaran, Vaishnavi
wrote:
> Hi Berkus,
>
> Thanks for your time and response.
>
> I do understand that there is no LIKE operator support for integers and it
> would be great if you could help me understand the reason why is it not
> supported.
>
> My intention
KERS] Differences in WHERE clause of SELECT
Prabakaran,
> I am a newbie to PostgreSQL and was wondering about the following
> behaviour.
pgsql-hackers is not the appropriate list for this kind of question. In the
future, please post to pgsql-novice, pgsql-sql, or pgsql-general with thi
Prabakaran,
> I am a newbie to PostgreSQL and was wondering about the following
> behaviour.
pgsql-hackers is not the appropriate list for this kind of question. In
the future, please post to pgsql-novice, pgsql-sql, or pgsql-general
with this kind of question. Thanks.
> Can you please help m
13 matches
Mail list logo
