On 12/24/23 13:43, Peter J. Holzer wrote:
On 2023-12-23 08:31:39 -0800, Adrian Klaver wrote:
I think you misunderstood Wilma. What she is asking for is a "keyword"
or "magic variable" (or whatever you want to call it) which you can
specify in CREATE|ALTER FUNCTION ... SET SEARCH_PATH = ...,
On 2023-12-23 08:31:39 -0800, Adrian Klaver wrote:
> On 12/23/23 08:12, Wilma Wantren wrote:
> > I had already feared that such a variable does not exist (because I
> > had not found it). I think that's a pity, because I suspect that in
> > at least 90% of the cases where a function needs a
On Sun, Dec 24, 2023 at 11:04 AM Johnathan Tiamoh
wrote:
>
> If so how was the backup done?
> It was taken with a customized script that uses pg_dump.
>
That's your problem: pg_dump is a logical backup. All the WAL records are
now completely invalid.
If you want PITR, read
On 12/24/23 08:03, Johnathan Tiamoh wrote:
Was this backup taken before the data directory was deleted?
Yes. I restored it from a 1-day old backup, but unfortunately, I
couldn't apply the logs.
If the backup was done using pg_dump as mentioned below why where you
applying logs?
You need
Was this backup taken before the data directory was deleted?
Yes. I restored it from a 1-day old backup, but unfortunately, I couldn't
apply the logs.
If so how was the backup done?
It was taken with a customized script that uses pg_dump.
Does this mean you recreated the data directory from
Dennis writes:
> The 16.x documentation still says the following:
> However, you can explicitly place |pg_catalog| at the end of your search
> path if you prefer to have user-defined names override built-in names.
It does work that way, for ordinary names. JSON_OBJECT is special
because it
Hi,
Predating PostgreSQL's json functions, I had been using custom json
functions, which by now have been reduced to wrappers around the native
type, but still using their original signatures so as to not have to
change hundreds of stored procedures. One of these is unfortunately
called
