st 15. 4. 2020 v 7:32 odesílatel Dilip Kumar napsal:
> One of our customers tried to use XMLTABLE syntax without
> row_expression, which works fine with ORACLE but doesn't work with
> PostgreSQL. So can anyone suggest what alternative we can use?
>
> CREATE TABLE user_pool_clean (
> fk_user_
st 15. 4. 2020 v 7:32 odesílatel Dilip Kumar napsal:
> One of our customers tried to use XMLTABLE syntax without
> row_expression, which works fine with ORACLE but doesn't work with
> PostgreSQL. So can anyone suggest what alternative we can use?
>
> CREATE TABLE user_pool_clean (
> fk_user_
On Wed, Apr 15, 2020 at 12:56 PM Pavel Stehule wrote:
> st 15. 4. 2020 v 7:32 odesílatel Dilip Kumar napsal:
>>
>> One of our customers tried to use XMLTABLE syntax without
>> row_expression, which works fine with ORACLE but doesn't work with
>> PostgreSQL. So can anyone suggest what alternative
I'm trying to restore a backup on a different machine and it terminates
with the not really helpful messages:
pg_restore: [directory archiver] could not close data file: Success
pg_restore: [parallel archiver] a worker process died unexpectedly
The backup was made with
pg_dump --compress=5 -v -F
On 2020-04-15 12:01:46 +0200, Peter J. Holzer wrote:
> I'm trying to restore a backup on a different machine and it terminates
> with the not really helpful messages:
>
> pg_restore: [directory archiver] could not close data file: Success
> pg_restore: [parallel archiver] a worker process died une
On 4/14/20 11:16 PM, Matthias Apitz wrote:
El día Dienstag, April 14, 2020 a las 08:28:35 -0700, Adrian Klaver escribió:
On 4/14/20 8:00 AM, Matthias Apitz wrote:
Hello,
The run (as user 'postgres') on the server of the cmd:
pg_basebackup -U ${DBSUSER} -Ft -z -D
/data/postgresql11/backup-w
Hello,
Does adding a GENERATED STORED column need to rewrite the table (like
adding a column with a DEFAULT before 11)? Neither the ALTER TABLE docs [1]
nor the generated column docs [2] discuss this. The former has a very nice
Tip regarding DEFAULT columns--maybe we should clarify GENERATED STORE
Hello all
We have some data that have entered a timestamp column from a csv. The data in
the csv are in utc. We want to access the data in our native timezone (CET).
I am considering a few alternatives:
1. Early in the process, convert to timestamptz and keep this datatype.
2. Ear
On Wed, Apr 15, 2020 at 7:50 PM Niels Jespersen wrote:
> Hello all
>
>
>
> We have some data that have entered a timestamp column from a csv. The
> data in the csv are in utc. We want to access the data in our native
> timezone (CET).
>
>
>
> I am considering a few alternatives:
>
>
>
> 1.
What is the exact format of the timestamp in the CSV? As long as it is in a
"fully qualified" format, i.e. includes the time-zone offset, then you will
have no problem as the data represents a point in time.
It is easier to conceptualize "time stamp with time zone" (timestamptz) as
actually repres
On Wed, Apr 15, 2020 at 11:06 AM Steve Crawford <
scrawf...@pinpointresearch.com> wrote:
> What is the exact format of the timestamp in the CSV? As long as it is in
> a "fully qualified" format, i.e. includes the time-zone offset, then you
> will have no problem as the data represents a point in t
Yes, the system will do a full table rewrite to compute the value and store
it. Unfortunately, I believe it is an access exclusive lock during that
entire time.
Niels Jespersen writes:
> Hello all
>
>
>
> We have some data that have entered a timestamp column from a csv. The data
> in the csv are in utc. We want to access the data in
> our native timezone (CET).
>
>
>
> I am considering a few alternatives:
>
>
>
> 1. Early in the process
Tim Cross wrote:
> Niels Jespersen writes:
>
> > Hello all
> >
> > We have some data that have entered a timestamp column from a csv. The data
> > in the csv are in utc. We want to access the data in
> > our native timezone (CET).
> >
> > I am considering a few alternatives:
> >
> > 1.
On Wed, Apr 15, 2020 at 4:53 PM raf wrote:
> I don't see much difference in storing a timestamptz in UTC or a
> timestamptz
> in CET. As long as the intended offset from UTC is recorded (which it is
> in a timestamptz) it should be fine.
>
I only really skimmed the entire response but this frami
Hello.
Added -hackers.
At Wed, 15 Apr 2020 12:14:25 +0200, "Peter J. Holzer" wrote
in
> On 2020-04-15 12:01:46 +0200, Peter J. Holzer wrote:
> > I'm trying to restore a backup on a different machine and it terminates
> > with the not really helpful messages:
> >
> > pg_restore: [directory arc
Fra: Magnus Hagander
Sendt: 15. april 2020 20:05
Til: Niels Jespersen
Cc: pgsql-general@lists.postgresql.org
Emne: Re: timestamp and timestamptz
On Wed, Apr 15, 2020 at 7:50 PM Niels Jespersen
mailto:n...@dst.dk>> wrote:
Hello all
We have some data that have entered a timestamp column from
On Thu, Apr 16, 2020 at 12:08:09PM +0900, Kyotaro Horiguchi wrote:
> I'm surprised to find an old thread about the same issue.
>
> https://www.postgresql.org/message-id/20160307.174354.251049100.horiguchi.kyotaro%40lab.ntt.co.jp
>
> But I don't think it's not acceptable that use fake errno for gz
18 matches
Mail list logo
