Re: Converting to identity columns with domains on PK columns

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
Cc: PegoraroF10 <marcos(at)f10(dot)com(dot)br>, pgsql-general(at)postgresql(dot)org
Subject: Re: Converting to identity columns with domains on PK columns
Date: 2019-07-05 22:32:31
Message-ID: 5124.1562365951@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> writes:
> On 7/5/19 1:49 PM, PegoraroF10 wrote:
>> Sorry, the example I was thinking was this one, which works on Firebird,
>> using its way of writing, obviously.
>> create function myproc(id integer) returns I32 language sql as 'select $1';
>>
>> On postgres ERROR: return type mismatch in function declared to return i32
>> What I mean is that Firebird sees I32 and integer as the same, Postgres
>> doesn´t.

> Yeah, but if you reverse the casting you did in your first example it works:
> create function myproc(id integer) returns I32 language sql as 'select
> $1::i32';
> CREATE FUNCTION

Yeah. This isn't an inherent property of Postgres, it's just that
SQL-language functions aren't defined to provide any implicit casting
of their results. The given expression must yield exactly the declared
function result type.

Most other places in PG are laxer and will automatically perform
implicit (and maybe assignment) casts for you. I don't remember
offhand whether there are good reasons for SQL functions to be
picky about this or it's just a shortage of round tuits. I have
a vague feeling that there might be some compatibility issues
in there, though.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2019-07-05 23:03:00 Re: Converting to identity columns with domains on PK columns
Previous Message Adrian Klaver 2019-07-05 21:10:52 Re: Converting to identity columns with domains on PK columns