Re: Some issues about data type convert

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Some issues about data type convert
Дата
Msg-id 15751.1262627100@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Some issues about data type convert  (Sam Mason <sam@samason.me.uk>)
Ответы Re: Some issues about data type convert
Re: Some issues about data type convert
Список pgsql-general
Sam Mason <sam@samason.me.uk> writes:
> Um, I think the OP is right.  Notice he does: ...
> showing that PG is auto-magically inserting a cast from BIGINT to OID.

Yes, as a quick look into pg_cast will show you, bigint -> oid is an
implicit cast:

regression=# \dC+ oid
                           List of casts
  Source type  |  Target type  |      Function      |   Implicit?
---------------+---------------+--------------------+---------------
 bigint        | oid           | oid                | yes
 integer       | oid           | (binary coercible) | yes
 oid           | bigint        | int8               | in assignment
 oid           | integer       | (binary coercible) | in assignment
 ...

The reason for this is that we want to be able to accept constants like
3000000000 as OIDs, but the lexer will initially mark that as bigint
because it doesn't fit in int4.

> The OP is saying that this isn't right because the cast isn't a total
> function, i.e. it fails for -1 and a large number of other inputs.

Sometimes usefulness has to trump consistency :-(.  It could actually be
argued that this is a consistency issue in itself.  Given a function
that takes OID, such as pg_database_size(oid), it would be unpleasant
if pg_database_size(16384) worked but pg_database_size(3000000000)
did not.

            regards, tom lane

В списке pgsql-general по дате отправления:

Предыдущее
От: Mark Williamson
Дата:
Сообщение: Re: Save MySQL? HA
Следующее
От: John DeSoi
Дата:
Сообщение: Re: how do I disable automatic start on mac os x?