| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Steve Rogerson <steve(dot)pg(at)yewtc(dot)demon(dot)co(dot)uk> |
| Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: postgres 11 issue? |
| Date: | 2019-07-03 19:36:56 |
| Message-ID: | 3061.1562182616@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Steve Rogerson <steve(dot)pg(at)yewtc(dot)demon(dot)co(dot)uk> writes:
>> It seems a bug to me. Can you share an anonymized/simplified definition
>> of that table that reproduces the problem?
> Ok See attached sql set up. I guess you need to to a createdb first.
It looks like what's happening is that the result of my_from_local()
is being stored into the table as an anonymous record value rather
than a value of type my_timestamp. (The originating session can figure
out what the anonymous record type is, but no other session can.)
That should be fixed, but in the meantime you could dodge the problem by
declaring my_from_local()'s v_result variable as my_timestamp not record.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Souvik Bhattacherjee | 2019-07-03 20:06:50 | Allocating shared memory in Postgres |
| Previous Message | Adrian Klaver | 2019-07-03 19:32:00 | Re: postgres 11 issue? |