Re: Converting to identity columns with domains on PK columns - Mailing list pgsql-general

From Tom Lane
Subject Re: Converting to identity columns with domains on PK columns
Date
Msg-id 5124.1562365951@sss.pgh.pa.us
Whole thread Raw
In response to Re: Converting to identity columns with domains on PK columns  (Adrian Klaver <adrian.klaver@aklaver.com>)
Responses Re: Converting to identity columns with domains on PK columns  (Adrian Klaver <adrian.klaver@aklaver.com>)
List pgsql-general
Adrian Klaver <adrian.klaver@aklaver.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



pgsql-general by date:

Previous
From: Adrian Klaver
Date:
Subject: Re: Converting to identity columns with domains on PK columns
Next
From: Adrian Klaver
Date:
Subject: Re: Converting to identity columns with domains on PK columns