On 27 November 2012 22:41, Tom Lane wrote:
> Merlin Moncure writes:
>> ... I think if you relaxed
>> the function sigs of a few functions on this page
>> (http://www.postgresql.org/docs/9.2/interactive/functions-string.html),
>> most reported problems would go away.
>
> That's an interesting way
On 12/14/2012 3:20 PM, Robert Haas wrote:
On Fri, Dec 14, 2012 at 2:11 PM, Tom Lane wrote:
Robert Haas writes:
... In more
than ten years of working with PostgreSQL, I've never encountered
where the restriction at issue here prevented a bug. It's only
annoyed me and broken my application co
On Fri, Dec 14, 2012 at 2:11 PM, Tom Lane wrote:
> Robert Haas writes:
>> ... In more
>> than ten years of working with PostgreSQL, I've never encountered
>> where the restriction at issue here prevented a bug. It's only
>> annoyed me and broken my application code (when moving from PostgreSQL
Robert Haas writes:
> ... In more
> than ten years of working with PostgreSQL, I've never encountered
> where the restriction at issue here prevented a bug. It's only
> annoyed me and broken my application code (when moving from PostgreSQL
> 8.2 to PostgreSQL 8.3, never mind any other database!)
On Tue, Dec 11, 2012 at 12:59 AM, Jeff Davis wrote:
> For every developer who says "wow, that mysql query just worked without
> modification" there is another one who says "oh, I forgot to test with
> option XYZ... postgres is too complex to support, I'm going to drop it
> from the list of support
On Tue, 2012-11-27 at 14:24 -0800, Jeff Davis wrote:
> On Tue, 2012-11-27 at 15:41 -0500, Robert Haas wrote:
> > I can't quite see how a non-overloaded flag would work, unless we get
> > rid of schemas.
>
> It may work to pick the first schema in the search path that has any
> functions by that na
On Tue, 2012-11-06 at 10:57 -0500, Robert Haas wrote:
> I did some experimentation with this. It seems that what Tom proposed
> here is a lot cleaner than what I proposed previously, while still
> increasing usability in many real-world cases. For example, in
> unpatched master:
It looks like we
I agree with Jeff.
Options that change the language at initdb or create-database time just fragment
the language.
It is best to just have 1 language where options are providable either
dynamically per connection or otherwise lexically, so that then they are really
just shorthands for the cur
On Mon, 2012-12-10 at 14:07 -0500, Robert Haas wrote:
> And we not only don't give them the behavior they want; we
> don't even have a meaningful way to give the option of opting into
> that behavior at initdb or create-database time.
I strongly object to offering options that change the language
Hello
2012/12/10 Robert Haas :
> On Tue, Nov 27, 2012 at 4:36 PM, Peter Eisentraut wrote:
>> On 11/25/12 6:36 PM, Robert Haas wrote:
>>> I think that is true. But for whatever it's worth, and at the risk of
>>> beating a horse that seems not to be dead yet in spite of the fact
>>> that I feel I'
On Tue, Nov 27, 2012 at 4:36 PM, Peter Eisentraut wrote:
> On 11/25/12 6:36 PM, Robert Haas wrote:
>> I think that is true. But for whatever it's worth, and at the risk of
>> beating a horse that seems not to be dead yet in spite of the fact
>> that I feel I've already administered one hell of a
I am aware that in the case at hand, the call to make_fn_arguments() is
with the only possible candidate function, so changing COERCE_IMPLICIT
to COERCE_ASSIGNMENT inside of make_fn_arguments() is correct. But I
wonder if this may have any unwanted side effects for other code paths
to make_fn_a
2012/11/28 Merlin Moncure :
> On Tue, Nov 27, 2012 at 4:41 PM, Tom Lane wrote:
>> Merlin Moncure writes:
>>> ... I think if you relaxed
>>> the function sigs of a few functions on this page
>>> (http://www.postgresql.org/docs/9.2/interactive/functions-string.html),
>>> most reported problems woul
On 11/27/12 2:41 PM, Tom Lane wrote:
Tweaking the casting rules could have a lot of
unforeseen consequences.
understatement of the year. IMHO. $0.02 worth etc.
--
john r pierceN 37, W 122
santa cruz ca mid-left coast
--
Sent via pgsql-
On Tue, Nov 27, 2012 at 4:41 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> ... I think if you relaxed
>> the function sigs of a few functions on this page
>> (http://www.postgresql.org/docs/9.2/interactive/functions-string.html),
>> most reported problems would go away.
>
> That's an interestin
Merlin Moncure writes:
> ... I think if you relaxed
> the function sigs of a few functions on this page
> (http://www.postgresql.org/docs/9.2/interactive/functions-string.html),
> most reported problems would go away.
That's an interesting way of approaching it. Do we have any data on
exactly wh
On Tue, 2012-11-27 at 15:41 -0500, Robert Haas wrote:
> I can't quite see how a non-overloaded flag would work, unless we get
> rid of schemas.
It may work to pick the first schema in the search path that has any
functions by that name, and then choose the overloaded (or not)
candidate from among
On Tue, Nov 27, 2012 at 4:09 PM, Peter Eisentraut wrote:
> On 11/27/12 12:07 PM, Merlin Moncure wrote:
>> Speaking of polymorphism, why not just implement lpad()'s first
>> argument as 'anyelement'?
>
> One of the arguments made here was that lpad(not-text) *should* fail.
Well, sure. My point is
On 11/27/12 12:07 PM, Merlin Moncure wrote:
> Speaking of polymorphism, why not just implement lpad()'s first
> argument as 'anyelement'?
One of the arguments made here was that lpad(not-text) *should* fail.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
On 11/25/12 7:21 PM, Robert Haas wrote:
> Sure, in theory that is true, but no other RDBMS that I know about
> feels a need to error out in that situation. I'm skeptical of the
> contention that we're smarter than everyone else.
Well, I think in most programming languages that have typed function
On 11/25/12 6:36 PM, Robert Haas wrote:
> I think that is true. But for whatever it's worth, and at the risk of
> beating a horse that seems not to be dead yet in spite of the fact
> that I feel I've already administered one hell of a beating, the LPAD
> case is unambiguous, and therefore it is ha
On Tue, Nov 27, 2012 at 3:21 PM, Tom Lane wrote:
> Robert Haas writes:
>> I do think that applying some kind of explicit flag to the function
>> indicating whether it should allow implicit assignment
>> casting/implicit casting to text/overloading/whatever is a possibly
>> interesting alternative
Robert Haas writes:
> On Tue, Nov 27, 2012 at 2:26 PM, Tom Lane wrote:
>> After making the change you propose above, it would only work for types
>> for which the cast was assignment-grade or less.
> ...but that's everything, because there's a hardcoded exception in the
> code that dictates that
On Tue, Nov 27, 2012 at 2:59 PM, Jeff Davis wrote:
> What user action are you concerned about? If we (eventually) made the
> non-overloaded case the default, would that resolve your concerns?
I can't quite see how a non-overloaded flag would work, unless we get
rid of schemas. But I think there
On Tue, Nov 27, 2012 at 2:26 PM, Tom Lane wrote:
> Uh, no, not really, and I think that assertion just goes to show that
> this area is more subtle than you think. quote_literal() for instance
> presently works for any datatype that has an explicit cast to text.
That doesn't appear to be the beh
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> It also affects developers, in that adding a
> new overloaded version of a system function (that previously wasn't
> overloaded) could actually reduce the number of cases for which the
> function works without an explicit cast.
>
> We have got to be really
Robert Haas writes:
> I do think that applying some kind of explicit flag to the function
> indicating whether it should allow implicit assignment
> casting/implicit casting to text/overloading/whatever is a possibly
> interesting alternative.
That idea seems possibly worth pursuing. The thing t
On Tue, 2012-11-27 at 14:13 -0500, Robert Haas wrote:
> I do think that applying some kind of explicit flag to the function
> indicating whether it should allow implicit assignment
> casting/implicit casting to text/overloading/whatever is a possibly
> interesting alternative. It seems clear from
Robert Haas writes:
> But as to your point about the system catalogs, it is true that adding
> an additional function could reduce the number of cases where things
> work today. But I think in many cases it would eliminate the need for
> overloading that we already have, and simplify things for f
On Tue, Nov 27, 2012 at 1:45 PM, Jeff Davis wrote:
> On Tue, 2012-11-27 at 12:19 -0500, Robert Haas wrote:
>> I admit that there are cases where this could happen, and that it will
>> happen a little more than it does now. But, as you say, this can
>> happen now, and yet we get very few if any co
On Tue, Nov 27, 2012 at 12:47 PM, Tom Lane wrote:
> Robert Haas writes:
>> I admit that there are cases where this could happen, and that it will
>> happen a little more than it does now. But, as you say, this can
>> happen now, and yet we get very few if any complaints about it,
>> whereas we g
On Tue, 2012-11-27 at 12:19 -0500, Robert Haas wrote:
> I admit that there are cases where this could happen, and that it will
> happen a little more than it does now. But, as you say, this can
> happen now, and yet we get very few if any complaints about it,
> whereas we get regular complaints ab
Robert Haas writes:
> I admit that there are cases where this could happen, and that it will
> happen a little more than it does now. But, as you say, this can
> happen now, and yet we get very few if any complaints about it,
> whereas we get regular complaints about the need to insert casts that
On Tue, Nov 27, 2012 at 4:46 AM, Jeff Davis wrote:
> Let's say you have only one function "foo". All your queries are coded
> into your application, and everything works fine, using assignment casts
> where necessary.
>
> Then the user is foolish enough to CREATE FUNCTION foo... and now their
> qu
On Tue, Nov 27, 2012 at 10:52 AM, Pavel Stehule 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 th
2012/11/27 Bruce Momjian :
> On Tue, Nov 27, 2012 at 01:59:04AM -0800, Jeff Davis wrote:
>> On Wed, 2012-11-21 at 15:27 +, Simon Riggs wrote:
>> > It would be useful if we issued a NOTICE when an ambiguity is
>> > introduced, rather than when using it.
>> >
>> > Like Bison's reporting of reduce
On Tue, Nov 27, 2012 at 01:59:04AM -0800, Jeff Davis wrote:
> On Wed, 2012-11-21 at 15:27 +, Simon Riggs wrote:
> > It would be useful if we issued a NOTICE when an ambiguity is
> > introduced, rather than when using it.
> >
> > Like Bison's reporting of reduce conflicts.
>
> This brings up a
Hello all
2012/11/27 Jeff Davis :
> On Wed, 2012-11-21 at 15:27 +, Simon Riggs wrote:
>> It would be useful if we issued a NOTICE when an ambiguity is
>> introduced, rather than when using it.
>>
>> Like Bison's reporting of reduce conflicts.
>
> This brings up a very important point, which is
On Wed, 2012-11-21 at 15:27 +, Simon Riggs wrote:
> It would be useful if we issued a NOTICE when an ambiguity is
> introduced, rather than when using it.
>
> Like Bison's reporting of reduce conflicts.
This brings up a very important point, which is that a lot of the code
is frozen in applic
On Sun, 2012-11-25 at 21:08 -0500, Robert Haas wrote:
> That, however, is a separate question from what's under discussion
> here, because the case at issue for the proposed patch is the one in
> which only one possible candidate exists, and the question is whether
> we ought to allow the use of as
On Sun, Nov 25, 2012 at 7:39 PM, Tom Lane wrote:
> I think this is ignoring the fact that we have an extensible type
> system, and thus a lot more room for problems if we allow too many
> implicit casts.
I don't deny that.
> It might also be worth noting that some of this complexity comes from
>
On Sun, Nov 25, 2012 at 6:46 PM, Tom Lane wrote:
> Robert Haas writes:
> I think we're talking past each other here. It is unarguable that
> (as long as there's only one LPAD function) there is only one possible
> non-error interpretation. However, you are ignoring the real
> possibility that p
On Sun, Nov 25, 2012 at 7:36 PM, Peter Geoghegan wrote:
> On 26 November 2012 00:24, Robert Haas wrote:
>> I remember this sort of thing un-fondly from my C++ days, but it
>> doesn't make me like our current behavior any better.
>
> You can also make a constructor with a single argument "explicit
Robert Haas writes:
> So I think the answer to your question is probably no, purely on the
> grounds that we have set a new world record for byzantine casting
> systems. A more fair comparison might be to look at what other SQL
> systems allow. Oracle, MySQL, and SQL Server all permit implicit
On 26 November 2012 00:24, Robert Haas wrote:
> I remember this sort of thing un-fondly from my C++ days, but it
> doesn't make me like our current behavior any better.
You can also make a constructor with a single argument "explicit", and
thereby prevent implicit conversions. So yes, C++ disting
On Sun, Nov 25, 2012 at 7:05 PM, Peter Geoghegan wrote:
> Well, you can make your class copy-constructable by providing a
> constructor (and a copy-assignment operator) whose only argument is,
> say, an int. In additional to that, you could potentially define a
> conversion operator, which will ma
On Sun, Nov 25, 2012 at 6:46 PM, Tom Lane wrote:
> I think we're talking past each other here. It is unarguable that
> (as long as there's only one LPAD function) there is only one possible
> non-error interpretation. However, you are ignoring the real
> possibility that perhaps the situation *i
On 25 November 2012 23:31, Robert Haas wrote:
> The only other programming
> language I know of in which you can define what it means to cast
> between two data types is C++, and it's not generally considered one
> of that languages better features. AFAICT, they have implicit casts
> and explicit
Robert Haas writes:
> On Thu, Nov 22, 2012 at 10:17 AM, Tom Lane wrote:
>> The argument here is basically between ease of use and ability to detect
>> common programming mistakes. It's not clear to me that there is any
>> principled way to make such a tradeoff, because different people can
>> re
> I'd be fine with that if we had a system that allows users to pick the
> behavior that they want in their particular environment, but in fact
> our existing system is extremely inflexible. If you start adding
> additional implicit casts to the system, you get failures trying to
> invoke commonl
On Thu, Nov 22, 2012 at 10:17 AM, Tom Lane wrote:
> The argument here is basically between ease of use and ability to detect
> common programming mistakes. It's not clear to me that there is any
> principled way to make such a tradeoff, because different people can
> reasonably put different weig
On Wed, Nov 21, 2012 at 5:10 PM, Peter Eisentraut wrote:
> Because a strongly-typed system should not cast numbers to strings
> implicitly. Does the equivalent of the lpad case work in any other
> strongly-typed programming language?
Does any other strongly-typed programming language distinguish
Peter Eisentraut writes:
> On 11/21/12 9:42 AM, Robert Haas wrote:
>> On Mon, Nov 19, 2012 at 6:19 PM, Peter Eisentraut wrote:
>>> I continue to be of the opinion that allowing this second case to work
>>> is not desirable.
>> 1. Why?
> Because a strongly-typed system should not cast numbers to
On 11/21/12 9:42 AM, Robert Haas wrote:
> On Mon, Nov 19, 2012 at 6:19 PM, Peter Eisentraut wrote:
>> On Tue, 2012-11-06 at 10:57 -0500, Robert Haas wrote:
>>> But, with the attached patch:
>>>
>>> rhaas=# create function xyz(smallint) returns smallint as $$select
>>> $1$$ language sql;
>>> CREATE
Simon Riggs writes:
> It would be useful if we issued a NOTICE when an ambiguity is
> introduced, rather than when using it.
I think that's pie in the sky, since whether there is an ambiguity
will depend not only on what set of functions exists, but what the
caller's search_path is.
On 29 August 2012 23:39, Tom Lane wrote:
> The main downside I can see is that code that used to work is likely
> to stop working as soon as someone creates a potential overloading
> situation. Worse, the error message could be pretty confusing, since
> if you had been successfully calling f(sma
On Mon, Nov 19, 2012 at 6:19 PM, Peter Eisentraut wrote:
> On Tue, 2012-11-06 at 10:57 -0500, Robert Haas wrote:
>> But, with the attached patch:
>>
>> rhaas=# create function xyz(smallint) returns smallint as $$select
>> $1$$ language sql;
>> CREATE FUNCTION
>> rhaas=# select xyz(5);
>> xyz
>> -
On Tue, 2012-11-06 at 10:57 -0500, Robert Haas wrote:
> But, with the attached patch:
>
> rhaas=# create function xyz(smallint) returns smallint as $$select
> $1$$ language sql;
> CREATE FUNCTION
> rhaas=# select xyz(5);
> xyz
> -
>5
> (1 row)
>
> rhaas=# create table abc (a int);
> CREA
On Thu, Aug 30, 2012 at 9:13 AM, Robert Haas wrote:
>> Upthread you were complaining about how we'd reject calls even when
>> there was only one possible interpretation. I wonder whether there'd be
>> any value in taking that literally: that is, allow use of assignment
>> rules when there is, in
On Wed, Aug 29, 2012 at 6:39 PM, Tom Lane wrote:
> Well, I see your point about LPAD(), but the problem is how to tell
> the difference between a harmless cast omission and an actual mistake
> that the user will be very grateful if we point out. If we allow
> implicit casts to text in the general
On Wed, Aug 29, 2012 at 06:39:37PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > On the more general issue, I continue to see minimal risk of harm
> > in allowing things like LPAD() to implicitly cast the first
> > argument to text.
>
> Well, I see your point about LPAD(), but the problem is h
Robert Haas writes:
> On the more general issue, I continue to see minimal risk of harm in
> allowing things like LPAD() to implicitly cast the first argument to
> text.
Well, I see your point about LPAD(), but the problem is how to tell
the difference between a harmless cast omission and an actu
On Wed, Aug 29, 2012 at 3:54 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 8/29/12 11:40 AM, Tom Lane wrote:
>>> regression=# select lpad(42,8);
>
>> We are not seriously intending to make the above query work, are we?
>
> Well, *I* don't want to, but apparently Robert does.
>
> I don't re
Peter Eisentraut writes:
> On 8/29/12 11:40 AM, Tom Lane wrote:
>> regression=# select lpad(42,8);
> We are not seriously intending to make the above query work, are we?
Well, *I* don't want to, but apparently Robert does.
I don't really want to go much further than finding a way to handle the
On 8/29/12 11:40 AM, Tom Lane wrote:
regression=# select lpad(42,8);
>>ERROR: failed to find conversion function from integer to text
>>I'm not sure why that's happening, either, but evidently some
>>additional coercion laxity would required.
>This, however, is a trivial problem; make_fn_argume
Robert Haas writes:
> The upshot here appears to be that we're kind of schizophrenic about
> what we want. With things like text || anyelement, anyelement ||
> text, and concat(variadic "any") we are basically asserting that we
> want to treat anything that we don't recognize as a string. But th
On 29/08/12 23:34, Robert Haas wrote:
On Wed, Aug 29, 2012 at 12:27 AM, Tom Lane wrote:
To put some concreteness into what so far has been a pretty hand-wavy
discussion, I experimented with the attached patch. I'm not sure that
it exactly corresponds to what you proposed, but I think this is th
On Wed, Aug 29, 2012 at 12:27 AM, Tom Lane wrote:
> To put some concreteness into what so far has been a pretty hand-wavy
> discussion, I experimented with the attached patch. I'm not sure that
> it exactly corresponds to what you proposed, but I think this is the
> only place the consideration co
On Tue, Aug 28, 2012 at 11:23 PM, Tom Lane wrote:
> That argument would hold water if we got rid of every single usage of
> overloading in the system-defined operators/functions, which as you well
> know is not an attractive idea. Since that's not going to happen,
> arguing for this on the basis
On Tue, Aug 28, 2012 at 9:47 PM, Tom Lane wrote:
> Robert Haas writes:
> > On Tue, Aug 28, 2012 at 2:55 PM, Tom Lane wrote:
> >> Oh, I'd forgotten that worked that way. Frankly, that makes me quite a
> >> bit more concerned about this proposal than I was before. I do *not*
> >> want to re-int
I wrote:
> Robert Haas writes:
>> That problem is dead.
> The reason it's dead is that we killed it in 8.3. I don't want it
> coming back to life, but I think that that will be exactly the outcome
> if we let any implicit casts to text get back into the rules for
> operator/function overloading
Robert Haas writes:
> On Tue, Aug 28, 2012 at 4:47 PM, Tom Lane wrote:
>> The real point here though is that the proposed
>> behavior change will affect all functions, not only the cases where you
>> think there is only one sane behavior. And features such as search paths
>> and default paramete
On Tue, Aug 28, 2012 at 4:47 PM, Tom Lane wrote:
>> Well, I think that when there is only one LPAD function, there is also
>> very little chance that the results will come out differently than the
>> user expected.
>
> [ shrug... ] I'm having a hard time resisting the temptation to point
> out th
On 08/29/2012 01:32 AM, Robert Haas wrote:
On Tue, Aug 28, 2012 at 1:06 PM, Tom Lane wrote:
Also, right at the moment it's not clear to me whether there are any
other cases besides integer literal vs smallint argument. I think
that's the only particularly surprising case within the numeric
hie
Robert Haas writes:
> On Tue, Aug 28, 2012 at 2:55 PM, Tom Lane wrote:
>> Oh, I'd forgotten that worked that way. Frankly, that makes me quite a
>> bit more concerned about this proposal than I was before. I do *not*
>> want to re-introduce silent cross-category casts to text, not even if
>> th
On Tue, Aug 28, 2012 at 2:55 PM, Tom Lane wrote:
> Oh, I'd forgotten that worked that way. Frankly, that makes me quite a
> bit more concerned about this proposal than I was before. I do *not*
> want to re-introduce silent cross-category casts to text, not even if
> there's no other way to match
Robert Haas writes:
> On Tue, Aug 28, 2012 at 1:39 PM, Tom Lane wrote:
>> There still won't be a candidate for that one, unless you're proposing
>> to allow explicit-only coercions to be applied implicitly.
> [ not so, see kluge in find_coercion_pathway() ]
Oh, I'd forgotten that worked that wa
On Tue, Aug 28, 2012 at 1:39 PM, Tom Lane wrote:
>> The other case that comes up regularly is someone trying to pass some
>> kind of number to a function such as LPAD(). There is only one LPAD()
>> so no ambiguity exists, but PostgreSQL doesn't even see that there's a
>> candidate.
>
> There stil
On 8/27/12 5:19 PM, Greg Sabino Mullane wrote:
Tom Lane replied:
>>>Come on, really? Note that the above example works without casts if
>>>you use int*or* bigint*or* numeric, but not smallint. That could be
>>>fixed by causing sufficiently-small integers to lex as smallints,
>>Is there any
Robert Haas writes:
> On Tue, Aug 28, 2012 at 1:06 PM, Tom Lane wrote:
>> Also, right at the moment it's not clear to me whether there are any
>> other cases besides integer literal vs smallint argument. I think
>> that's the only particularly surprising case within the numeric
>> hierarchy ---
On Tue, Aug 28, 2012 at 1:06 PM, Tom Lane wrote:
> Also, right at the moment it's not clear to me whether there are any
> other cases besides integer literal vs smallint argument. I think
> that's the only particularly surprising case within the numeric
> hierarchy --- and for non-numeric types,
Greg Stark writes:
> Perhaps just a warning on CREATE FUNCTION when one of the arguments
> doesn't have an implicit cast from the canonical data type of that
> hierarchy saying perhaps you should consider using that data type and
> let Postgres convert instead of the more specific data type?
This
On Mon, Aug 27, 2012 at 10:03 PM, Robert Haas wrote:
> We really ought to put some effort into solving this problem. I've
> seen a few Oracle-migration talks at conferences, and *every one* of
> them has mentioned the smallint problem. It hits our customers, too.
I'm kind of puzzled how Oracle-
On Mon, Aug 27, 2012 at 7:13 PM, Tom Lane wrote:
> Robert Haas writes:
>> I agree that redefining the lexer behavior is a can of worms. What I
>> don't understand is why f(2+2) can't call f(smallint) when that's the
>> only extant f. It seems to me that we could do that without breaking
>> anyt
Robert Haas writes:
> I agree that redefining the lexer behavior is a can of worms. What I
> don't understand is why f(2+2) can't call f(smallint) when that's the
> only extant f. It seems to me that we could do that without breaking
> anything that works today: if you look for candidates and do
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Tom Lane replied:
>>> Come on, really? Note that the above example works without casts if
>>> you use int *or* bigint *or* numeric, but not smallint. That could be
>>> fixed by causing sufficiently-small integers to lex as smallints,
>> Is th
On Mon, Aug 27, 2012 at 4:03 PM, Tom Lane wrote:
> Bruce Momjian writes:
>> On Fri, Feb 17, 2012 at 02:52:20PM -0500, Robert Haas wrote:
>>> Come on, really? Note that the above example works without casts if
>>> you use int *or* bigint *or* numeric, but not smallint. That could be
>>> fixed by
On Mon, Aug 27, 2012 at 04:03:05PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Fri, Feb 17, 2012 at 02:52:20PM -0500, Robert Haas wrote:
> >> Come on, really? Note that the above example works without casts if
> >> you use int *or* bigint *or* numeric, but not smallint. That could be
>
Bruce Momjian writes:
> On Fri, Feb 17, 2012 at 02:52:20PM -0500, Robert Haas wrote:
>> Come on, really? Note that the above example works without casts if
>> you use int *or* bigint *or* numeric, but not smallint. That could be
>> fixed by causing sufficiently-small integers to lex as smallints
On Fri, Feb 17, 2012 at 02:52:20PM -0500, Robert Haas wrote:
> Here's yet another case where the current rules are thoroughly disagreeable.
>
> rhaas=# create or replace function z(smallint) returns smallint as
> $$select $1+1$$ language sql;
> ERROR: return type mismatch in function declared to
On Fri, Feb 17, 2012 at 7:12 PM, Josh Berkus wrote:
> On 2/17/12 12:04 PM, Robert Haas wrote:
>> The argument isn't about whether the user made the right design
>> choices; it's about whether he should be forced to insert an explicit
>> type cast to get the query to do what it is unambiguously int
On Sat, Feb 18, 2012 at 4:12 PM, Don Baccus wrote:
> On Feb 18, 2012, at 12:57 PM, Rob Wultsch wrote:
>>
>> Where first_name is string the queries above have very different
>> behaviour in MySQL. The first does a full table scan and coerces
>> first_name to an integer (so '5adfs' -> 5)
>
> Oh my,
On Sat, Feb 18, 2012 at 5:34 PM, Don Baccus wrote:
>
> On Feb 18, 2012, at 1:43 PM, Christopher Browne wrote:
>> A hierarchy like the following is perfectly logical:
>> - to 0999 :: Cash accounts [1]
>
> I asked earlier if anyone would expect 01 like '0%' to match …
>
> Apparently so!
Yes, a
On 02/18/2012 05:34 PM, Don Baccus wrote:
On Feb 18, 2012, at 1:43 PM, Christopher Browne wrote:
On Sat, Feb 18, 2012 at 4:12 PM, Don Baccus wrote:
On Feb 18, 2012, at 12:57 PM, Rob Wultsch wrote:
Where first_name is string the queries above have very different
behaviour in MySQL. The firs
Don Baccus writes:
>> A hierarchy like the following is perfectly logical:
>> - to 0999 :: Cash accounts [1]
>
> Your example is actually a good argument for storing account ids as
> text, because '' like '0%' *will* match.
FWIW, I too think that if you want to process your integers as t
On Feb 18, 2012, at 1:43 PM, Christopher Browne wrote:
> On Sat, Feb 18, 2012 at 4:12 PM, Don Baccus wrote:
>>
>> On Feb 18, 2012, at 12:57 PM, Rob Wultsch wrote:
>>>
>>> Where first_name is string the queries above have very different
>>> behaviour in MySQL. The first does a full table scan a
On Sat, Feb 18, 2012 at 4:12 PM, Don Baccus wrote:
>
> On Feb 18, 2012, at 12:57 PM, Rob Wultsch wrote:
>>
>> Where first_name is string the queries above have very different
>> behaviour in MySQL. The first does a full table scan and coerces
>> first_name to an integer (so '5adfs' -> 5)
>
> Oh my
On Feb 18, 2012, at 12:57 PM, Rob Wultsch wrote:
>
> Where first_name is string the queries above have very different
> behaviour in MySQL. The first does a full table scan and coerces
> first_name to an integer (so '5adfs' -> 5)
Oh my, I can't wait to see someone rise to the defense of *this*
On Fri, Feb 17, 2012 at 4:12 PM, Josh Berkus wrote:
> On 2/17/12 12:04 PM, Robert Haas wrote:
>> The argument isn't about whether the user made the right design
>> choices; it's about whether he should be forced to insert an explicit
>> type cast to get the query to do what it is unambiguously int
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> The time I got bitten by this was actually with LPAD(), rather than LIKE.
+1. This is one of the functions that gave some of our clients
real trouble when 8.3 came out.
> If we really believed that implicit casts any form were evil, we
> w
1 - 100 of 122 matches
Mail list logo
