Thanks for the reply.
I agree with your solution in principle, but I have nearly 100 databases
so far across several servers and many at customer sites. I am trying to
migrate some from and maintain compatibility with MS SQLServer.
These quantities have been smallint for quite some time. Changing the
underlying database types now would be a problem.
I can cast inside the function, this is my current solution. Given that
there is no implicit downcast wouldn't the best solution be to get the
ODBC driver do the cast on the function call?
On 13 Mar 2004 at 19:40, Tom Lane wrote:
> Gary Doades <gpd(at)cwcom(dot)net> writes:
> > I have delcared a pg function as:
> > function GENERATE_TIMESHEETS(timestamp,timestamp,smallint,smallint)
> > ....
> You're probably best off to declare the inputs as integer not smallint.
> Integer literals are assumed to be int4 by default, and since there's
> no implicit downcast to int2 (anymore), writing a function this way will
> require you to cast to smallint explicitly a lot. It's seldom worth
> that notational hassle. You can cast inside the function if you really
> need the values to be int2 inside it.
> regards, tom lane
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
In response to
pgsql-odbc by date
|Next:||From: Tom Lane||Date: 2004-03-14 17:30:09|
|Subject: Re: ODBC int2 parameters to pg function |
|Previous:||From: Shachar Shemesh||Date: 2004-03-14 06:26:47|
|Subject: Re: ERROR: column "ctid" does not exist|