On 17 Feb 2022, at 8:02, Carsten Klein wrote:
> We have a trigger, that monitors such updates and it reports a changed value,
> which is not correct. The problem is, that the assignment
>
> SET xyz = 1.56
>
> actually means
>
> SET xyz = 1.55999
>
> since getting a double value from the
On Wed, Feb 16, 2022 at 08:11 PM David G. Johnston wrote:
You said they are more or less the same. Problems like these tend to
hide in the "less" portion of the inequality.
On of the virtualized servers was created as a clone of the other one
(using VMware to clone the VM). So,
On Wed, Feb 16, 2022 at 11:38 AM Carsten Klein wrote:
>
>
> On Wed, Feb 16, 2022 at 05:46 PM Adrian Klaver wrote
> > On 2/16/22 05:27, Carsten Klein wrote:
> >> Hi there,
> >>
> >> I'm using several (now unsupported) PostgreSQL 9.3.24 servers on
> >> different (ancient) Ubuntu 14.04 LTS
On Wed, Feb 16, 2022 at 05:46 PM Adrian Klaver wrote
On 2/16/22 05:27, Carsten Klein wrote:
Hi there,
I'm using several (now unsupported) PostgreSQL 9.3.24 servers on
different (ancient) Ubuntu 14.04 LTS machines. On only one of those
servers, I get strange/wrong results when converting a
On Wed, 2022-02-16 at 14:36 +0100, Alexander Farber wrote:
> Ah, I have to do
>
> RETURN '___WRONG___';
>
> and not
>
> out_text := '___WRONG___'
> RETURN;
Yes. As I said, a trivial error.
Yours,
Laurenz Albe
On 2/16/22 02:30, celati Laurent wrote:
Good morning,
I created a new table yesterday. I am superuser and I have all the
rights. I had no worries yesterday to make editions on this table.
Today all my fields are in readonly mode. As this post illustrates:
Good morning,
I created a new table yesterday. I am superuser and I have all the rights.
I had no worries yesterday to make editions on this table.
Today all my fields are in readonly mode. As this post illustrates:
On 2/16/22 05:27, Carsten Klein wrote:
Hi there,
I'm using several (now unsupported) PostgreSQL 9.3.24 servers on
different (ancient) Ubuntu 14.04 LTS machines. On only one of those
servers, I get strange/wrong results when converting a string into a
double value:
Has anyone an idea of
s/grumbling/wondering/
Ah, thank you Ralf! That has explained it (because I was still grumbling...)
On Wed, Feb 16, 2022 at 4:44 PM Ralf Schuchardt wrote:
> You must rather end the assignment with a semicolon:
>
> out_text := '___WRONG___';
> RETURN;
>
> Otherwise what really happens is:
>
> out_text := '___WRONG___'
On 16 Feb 2022, at 14:36, Alexander Farber wrote:
> Ah, I have to do
>
> RETURN '___WRONG___';
Not necessarily.
> and not
>
> out_text := '___WRONG___'
> RETURN;
You must rather end the assignment with a semicolon:
out_text := '___WRONG___';
RETURN;
Otherwise
Ah, I have to do
RETURN '___WRONG___';
and not
out_text := '___WRONG___'
RETURN;
Hi Laurenz, thanks for your reply, but I think it is wrong -
On Wed, Feb 16, 2022 at 1:24 PM Laurenz Albe
wrote:
> One reason could be index corruption. If one query uses an index and the
> other doesn't,
> that could lead to different results.
>
> The other option is of course a trivial
Hi there,
I'm using several (now unsupported) PostgreSQL 9.3.24 servers on
different (ancient) Ubuntu 14.04 LTS machines. On only one of those
servers, I get strange/wrong results when converting a string into a
double value:
SELECT 1.56::double precision;
--> 1.55 (wrong!)
Hi Laurenz
Means that is what I am thinking even right now if we can move the
partition to another tablespace and have file system level compression.
Apart from this do we have any other solution or strategy which I can try
to implement?
On Wed, Feb 16, 2022 at 6:13 PM Laurenz Albe
wrote:
>
On Wed, 2022-02-16 at 18:10 +0530, Jagmohan Kaintura wrote:
> We have a requirement where we wanted to keep the partitions holding the old
> data into compressed
> format and the partition having the current data in the non-compressed format.
> While looking over the compression aspects in Pg 14
Hi Team,
We have a requirement where we wanted to keep the partitions holding the
old data into compressed format and the partition having the current data
in the non-compressed format.
While looking over the compression aspects in Pg 14 we have some
compression introduced for the column level
On Wed, 2022-02-16 at 11:51 +0100, Alexander Farber wrote:
> when I search for a non existent word in the two tables hosted in PostgreSQL
> 14.1 then I get zero records as expected:
>
> words_en=> SELECT 1 FROM words_nouns WHERE word = 'ABCDE' UNION SELECT 1 FROM
> words_verbs WHERE word =
Hello,
when I search for a non existent word in the two tables hosted in
PostgreSQL 14.1 then I get zero records as expected:
words_en=> SELECT 1 FROM words_nouns WHERE word = 'ABCDE' UNION SELECT 1
FROM words_verbs WHERE word = 'ABCDE';
?column?
--
(0 rows)
But when I try to use the
Am Wed, Feb 16, 2022 at 01:27:56AM + schrieb Shaozhong SHI:
> Is there a way to automatically scan a table and report the format of data
> for each column?
pg_class
But you may want to rethink the approach given that you use Python.
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80
20 matches
Mail list logo
