Thank you for the information.
After testing, I found that I only need to escape the following 7 characters.
% → %25
" → %22
' → %27
+ → %2B
; → %3B
= → %3D
{ → %7B
At 2022-10-13 13:27:16, "Jeffrey Walton" wrote:
>On Thu, Oct 13, 2022 at 12:13 AM gzh wrote:
>>
>> My PostgreSQL
> On 13/10/2022 19:16 CEST Tom Lane wrote:
>
> Erik Wienhold writes:
> > On 13/10/2022 18:20 CEST Adrian Klaver wrote:
> >> select power(10, -18::numeric);
> >> power
> >>
> >> 0.
> >>
> >> Why is the cast throwing off the result?
>
> > Calling
On 10/13/22 12:45, Thomas Kellerer wrote:
Tom Lane schrieb am 13.10.2022 um 21:01:
When trying pg_upgrade to upgrade Postgres 14 to 15 on Windows 10
Hmm, the xml2 extension is not installed in any of those databases.
Most databases were probably migrated over time from 8.4
and I can't rule
Tom Lane schrieb am 13.10.2022 um 21:01:
When trying pg_upgrade to upgrade Postgres 14 to 15 on Windows 10 this fails
with:
pg_restore: error: could not execute query: ERROR: could not find function
"xml_is_well_formed" in file "c:/Program Files/PostgreSQL/15/lib/pgxml.dll"
I don't
Dean Rasheed writes:
> The most obvious thing to do is to try to make power_var_int() choose
> the same result rscale as power_var() so that the results are
> consistent regardless of whether the exponent is an integer.
Yeah, I think we should try to end up with that.
> It's worth noting,
On Thu, 13 Oct 2022 at 18:17, Tom Lane wrote:
>
> I'm inclined to think that we should push the responsibility for choosing
> its rscale into power_var_int(), because internally that already does
> estimate the result weight, so with a little code re-ordering we won't
> need duplicative
Thomas Kellerer writes:
> When trying pg_upgrade to upgrade Postgres 14 to 15 on Windows 10 this fails
> with:
> pg_restore: error: could not execute query: ERROR: could not find function
> "xml_is_well_formed" in file "c:/Program Files/PostgreSQL/15/lib/pgxml.dll"
> I don't understand why
When trying pg_upgrade to upgrade Postgres 14 to 15 on Windows 10 this fails
with:
pg_restore: creating FUNCTION "public.xml_is_well_formed("text")"
pg_restore: while PROCESSING TOC:
pg_restore: from TOC entry 647; 1255 23216 FUNCTION xml_is_well_formed("text")
postgres
pg_restore: error:
Erik Wienhold writes:
> On 13/10/2022 18:20 CEST Adrian Klaver wrote:
>> select power(10, -18::numeric);
>> power
>>
>> 0.
>>
>> Why is the cast throwing off the result?
> Calling power(numeric, numeric) is what I expect in that case instead of
>
On 2022-10-13 09:20:51 -0700, Adrian Klaver wrote:
> In trying to answer an SO question I ran across this:
>
> Postgres version 14.5
>
Same for 11.17. So it's been like that for some time, maybe forever.
> select power(10, -18);
> power
> ---
> 1e-18
> (1 row)
>
> select power(10,
> On 13/10/2022 18:20 CEST Adrian Klaver wrote:
>
> In trying to answer an SO question I ran across this:
>
> Postgres version 14.5
>
> select 10^(-1 * 18);
> ?column?
> --
> 1e-18
>
> select 10^(-1 * 18::numeric);
>?column?
>
> 0.
In trying to answer an SO question I ran across this:
Postgres version 14.5
select 10^(-1 * 18);
?column?
--
1e-18
select 10^(-1 * 18::numeric);
?column?
0.
Same for power:
select power(10, -18);
power
---
1e-18
(1 row)
select
The primary's recovery.conf looks like this
listen_address='*'
wal_level=replica
synchronous_commit=local
archive_move = on
archive_command = 'cp %p /var/lib/pgsql/11/data/archive/%f'
max_wal_senders = 10
wal_keep_segments=10
synchronous_standby_names='standby0'
wal_log_hints=on
On Sun, Oct 9,
On Thu, Oct 13, 2022 at 08:04:03AM +, Eagna wrote:
>
> > > ERROR: syntax error at or near "WHERE"
> > > LINE 10: WHERE o.total_price > ISNULL(sub.paid, 0);
>
>
> > There error here is because a JOIN clause requires a join condition. Adding
> > an
> > "ON true" is probably what you want. You
> > ERROR: syntax error at or near "WHERE"
> > LINE 10: WHERE o.total_price > ISNULL(sub.paid, 0);
> There error here is because a JOIN clause requires a join condition. Adding an
> "ON true" is probably what you want. You would also need to change isnull()
> with coalesce().
> The final
Hi,
On Thu, Oct 13, 2022 at 07:05:48AM +, Eagna wrote:
>
> relatively simple one would have thought! I tried to convert this into a
> Postgres query as follows:
>
> SELECT o.order_id,
> o.total_price - COALESCE(sub.paid, 0)
> FROM _order o
> LEFT JOIN LATERAL (
> SELECT SUM(p.amount)
Good Morning all,
I am having a problem understanding a simple LATERAL join - I'm working on
grasping them.
All tables and data are at the bottom of this question and on the fiddles, SQL
Server (working) and Postgres (not working).
SQL Server fiddle - https://dbfiddle.uk/hjBBd87B
Postgres
17 matches
Mail list logo
