Hi,
I'm using the following in an SQL :
select (EACH(value)).key as measurement_key,
(EACH(value)).value as value
from t_reading_hstore;
I'm assuming this will give two columns containing the key/value pairs in the
hstore record.
The docs suggest the order of the keys/values returned is
On Thursday, March 11, 2021, Brent Wood wrote:
> Hi,
>
> I'm using the following in an SQL :
>
> select (EACH(value)).key as measurement_key,
>(EACH(value)).value as value
> from t_reading_hstore;
>
>
Just move the each call to the from clause as a lateral join and treat the
result as a t
Hi
On 2021-03-12 04:46, Brent Wood wrote:
Hi,
I'm using the following in an SQL :
select (EACH(value)).key as measurement_key,
(EACH(value)).value as value from t_reading_hstore;
I'm assuming this will give two columns containing the key/value pairs
in the hstore record.
The docs su
From: David G. Johnston
Sent: Friday, March 12, 2021 21:19
To: Brent Wood
Cc: pgsql-general@lists.postgresql.org
Subject: Re: hstore each() function - returned order??
Thanks David,
Is this what you mean?
select measurement_key,
value
from t_reading_hstore,
lateral ((EACH(value))
On Fri, Mar 12, 2021 at 3:18 AM Brent Wood wrote:
> *From:* David G. Johnston
> *Sent:* Friday, March 12, 2021 21:19
> *To:* Brent Wood
> *Cc:* pgsql-general@lists.postgresql.org <
> pgsql-general@lists.postgresql.org>
> *Subject:* Re: hstore each() function - returned order??
>
>
> Thanks Davi
"David G. Johnston" writes:
> On Fri, Mar 12, 2021 at 3:18 AM Brent Wood wrote:
>> Is this what you mean?
>>
>> select measurement_key,
>> value
>> from t_reading_hstore,
>> lateral ((EACH(value)).key as measurement_key,
>> lateral ((EACH(value)).value as value;
> The definition of "each" shows
Ahh, light dawns!!!
Thanks guys, much appreciated!!! (as always)
Brent
On Saturday, March 13, 2021, 3:52:33 AM GMT+13, Tom Lane
wrote:
"David G. Johnston" writes:
> On Fri, Mar 12, 2021 at 3:18 AM Brent Wood wrote:
>> Is this what you mean?
>>
>> select measurement_key,
>> value
>
Resurrecting an old thread.
We (AWS) have seen this wraparound during pg_upgrade more often recently
with customers who have millions of large objects in their databases.
On 6/11/18 1:14 PM, Tom Lane wrote:
Andres Freund writes:
I suspect the issue is that pg_resetwal does:
if (set_
Hi Jan,
On Fri, Mar 12, 2021 at 06:13:33PM -0500, Jan Wieck wrote:
> One of the things in my way is that when using pg_resetwal to put the
> NextXID way into the future (to push the old cluster close to wraparound for
> example), the postmaster won't start because it doesn't have the pg_xact
> fil
