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 по дате отправления: