Re: Odd behavior with 'currval'

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.

In response to

Responses

Browse pgsql-general by date

  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'