On Mon, Jan 04, 2010 at 12:45:00PM -0500, Tom Lane wrote: > Sam Mason <sam@xxxxxxxxxxxxx> 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: Oops, I should have pointed this out to the OP! > 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. What's wrong with getting users to put quotes around OIDs? Backwards compatibility seems like an awkward one to maintain when doing this. > > 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 :-(. One technical solution I've seen used elsewhere is to introduce the concept of a "numeric literal". For example, Haskell's parser knows about both "numbers" and "fractional numbers" and types can be declared as supporting either numeric constants or both numeric and fractional constants. This would seem to complicate the simple type inference that PG does, but not too badly. > 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. Not sure what you're saying here, but I don't think it matters. -- Sam http://samason.me.uk/ -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
