Tom Lane wrote:
> Thomas Lockhart <[EMAIL PROTECTED]> writes:
> >> It's one thing to say that "apples || oranges" should
> >> be interpreted as "apples::text || oranges::text", but it is quite
> >> another to say that "apples <= oranges" should be handled that way.
>
> > Hmm. istm that we might n
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> Wow, I am completely at a loss why you would not allow implicit coercions
> that do not loose any data in the process.
Haven't you read the previous threads? Implicit coercions are
dangerous, because they cause the system to resolve oper
> The lines marked XXX are the ones that I enabled since yesterday, and
> would like to disable again:
>
> implicit | result|input|prosrc
> --+-+-+--
> no | varchar | int8
> I suspect that the main thing that will cause issues is removal of
> implicit coercions to text. For example, in 7.2 and before you can do
>
> test72=# select 'At the tone, the time will be ' || now();
> ?column?
>
Since it seems we still want to debate this a little, I've modified the
initial set of implicit-coercion-allowed flags to allow silent coercions
from the standard datatypes to text. This un-breaks most of the
regression tests that were failing before. I still want to debate the
wisdom of allowin
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> We have never been in complete agreement on the optimal behavior for
> type coersion, but it seems that most users are blissfully ignorant of
> the potential downsides of the current behavior. Another way to phrase
> that would be to say that it actual
...
> Since I didn't see an immediate batch of squawks, I think I will go
> ahead and commit what I have; we can always revisit the implicit-allowed
> flag settings later.
Squawk. But I haven't had time to look at the full ramifications of your
proposed change, so it is inappropriate to comment,
Barry Lind <[EMAIL PROTECTED]> writes:
> OK. My mistake. In looking at the regression failures in your post, I
> thought I saw errors being reported of this type. My bad.
Well, although that particular case isn't a problem, I am sure that this
change will break some existing applications ---
OK. My mistake. In looking at the regression failures in your post, I
thought I saw errors being reported of this type. My bad.
--Barry
Tom Lane wrote:
> Barry Lind <[EMAIL PROTECTED]> writes:
>
>>My feeling is that this change as currently scoped will break a lot of
>>existing apps. Espe
Barry Lind <[EMAIL PROTECTED]> writes:
> My feeling is that this change as currently scoped will break a lot of
> existing apps. Especially the case where people are using where clauses
> of the form: bigintcolumn = '999' to get a query to use the index on
> a column of type bigint.
Eh? T
Tom,
My feeling is that this change as currently scoped will break a lot of
existing apps. Especially the case where people are using where clauses
of the form: bigintcolumn = '999' to get a query to use the index on
a column of type bigint.
thanks,
--Barry
Tom Lane wrote:
> Awhile back
Awhile back I suggested adding a boolean column to pg_proc to control
which type coercion functions could be invoked implicitly, and which
would need an explicit cast:
http://archives.postgresql.org/pgsql-hackers/2001-11/msg00803.php
There is a relevant bug report #484 showing the dangers of too m
12 matches
Mail list logo
