From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Joel Burton <joel(at)joelburton(dot)com> |
Cc: | "Andrew J(dot) Kopciuch" <akopciuch(at)bddf(dot)ca>, Yonatan Ben-Nes <da(at)canaan(dot)co(dot)il>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Functions just dont want to work! [hard] |
Date: | 2002-12-04 21:30:18 |
Message-ID: | 18540.1039037418@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Joel Burton <joel(at)joelburton(dot)com> writes:
> But the constant 24 in PG is parsed as an int4 not an int2, and PG isn't
> coercing it automatically to an int2 for the function.
Yes. This is an intermediate state; eventually I'd like 24 to be parsed
as an int2 and then implicitly up-converted if it's used in a context
where int4 is needed. However we are not there yet --- I posted a
message on pghackers a few weeks ago about the problems that occurred in
an initial attempt to make that happen. It breaks a lot of cases that
work at the moment :-(
There are a number of tradeoffs to be made here --- it's difficult to
find a workable compromise between being flexible and being too flexible
(ie, having the parser fail because it can't decide which alternative
to pick). See the many threads about implicit coercions in the
pghackers archives if you want to contribute ideas.
Right at the moment I'm toying with the notion of using assignment
coercion not implicit coercion when there is only one possible candidate
function (ie, the name and number of arguments uniquely identifies the
function) --- but I'm not sure how much that will help. It might just
confuse people even more.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-12-04 21:36:43 | Re: Query breaking with unknown expression type (lost subquery from v iew?) |
Previous Message | scott.marlowe | 2002-12-04 21:26:02 | Re: pg and number of parameters by insert |