From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Steven Hirsch <snhirsch(at)gmail(dot)com> |
Cc: | "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Odd behavior with 'currval' |
Date: | 2018-02-08 21:27:38 |
Message-ID: | CAKFQuwaLWdEp64f0RWZbM-F-fzzE_Qe3mMXH_s7THJ=TR1A9iA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, Feb 8, 2018 at 2:22 PM, Steven Hirsch <snhirsch(at)gmail(dot)com> wrote:
> On Thu, 8 Feb 2018, David G. Johnston wrote:
>
> On Thu, Feb 8, 2018 at 12:54 PM, David G. Johnston <
>> david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>> The only 'currval' procedure is the one defined at
>> installation (in public).
>>
>>
>> So, the installed version of currval would be defined in "pg_catalog",
>> not "public" ...
>>
>
> ??
>
> All I can tell you is that when I connect from dbVisualizer and open the
> twisty under 'main.procedures' I see 100+ functions that are intrinsic to
> pgsql - currval() included. I have almost no experience writing pgsql
> procs and absolutely never installed anything that would override the base
> function.
>
Just to be certain, what does "\dfS+ currval" output in psql?
I'll agree this would be highly unusual but I so would this being a bug.
And the oddity with the lost sequence ownership...
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | Steven Hirsch | 2018-02-08 21:52:07 | Re: Odd behavior with 'currval' |
Previous Message | Steven Hirsch | 2018-02-08 21:22:39 | Re: Odd behavior with 'currval' |