čt 8. 11. 2018 v 7:34 odesílatel Andrew Gierth
napsal:
> > "Pavel" == Pavel Stehule writes:
>
> Pavel> The variadic parameters should not be a arrays - can be of "any"
> Pavel> type. But this functionality is available only for C language
> Pavel> functions.
>
> You mean (VARIADIC "any")?
> "Pavel" == Pavel Stehule writes:
Pavel> The variadic parameters should not be a arrays - can be of "any"
Pavel> type. But this functionality is available only for C language
Pavel> functions.
You mean (VARIADIC "any")? - that is not actually restricted to C
language functions, any pl/*
On Wed, Nov 7, 2018 at 10:10 PM Andrew Gierth
wrote:
>
> But you don't need to create more functions, because you can do this:
>
> select largest(variadic array[1,2,3]);
> largest
> -
>3
>
>
> As already pointed out, greatest() and least() exist (though they were
> added before
čt 8. 11. 2018 v 7:11 odesílatel Andrew Gierth
napsal:
> > "Ken" == Ken Tanzer writes:
>
> Ken> Hi. Building on the [type]_larger and _smaller functions (and
> Ken> lifting from the documentation), I put together a couple of
> Ken> functions that will take any number of arguments:
>
> Ke
> "Ken" == Ken Tanzer writes:
Ken> Hi. Building on the [type]_larger and _smaller functions (and
Ken> lifting from the documentation), I put together a couple of
Ken> functions that will take any number of arguments:
Ken> CREATE FUNCTION largest(VARIADIC anyarray) RETURNS anyelement AS
čt 8. 11. 2018 v 7:02 odesílatel Ken Tanzer napsal:
>
>
> On Wed, Nov 7, 2018 at 9:48 PM Pavel Stehule
> wrote:
>
>>
>> You can pass variadic arguments as a array
>>
>> postgres=# \sf smallest
>> CREATE OR REPLACE FUNCTION public.smallest(VARIADIC anyarray)
>> RETURNS anyelement
>> LANGUAGE sq
On Wed, Nov 7, 2018 at 9:48 PM Pavel Stehule
wrote:
>
> You can pass variadic arguments as a array
>
> postgres=# \sf smallest
> CREATE OR REPLACE FUNCTION public.smallest(VARIADIC anyarray)
> RETURNS anyelement
> LANGUAGE sql
> IMMUTABLE
> AS $function$
> SELECT min($1[i]) FROM generate_s
st 7. 11. 2018 v 22:38 odesílatel Ken Tanzer napsal:
> Hi. Building on the [type]_larger and _smaller functions (and lifting
> from the documentation), I put together a couple of functions that will
> take any number of arguments:
>
> CREATE FUNCTION largest(VARIADIC anyarray) RETURNS anyelement
On 8 November 2018 at 15:28, Paul Schaap wrote:
> I have an issue, and a partial workaround, with a query outlined below. What
> I am hoping to get to is a Parallel Index Only Scan on my partition indexes
> as theoretically that should be the fastest, but can only get either a
> Parallel Seq Scan
Hi,
I have an issue, and a partial workaround, with a query outlined below. What I
am hoping to get to is a Parallel Index Only Scan on my partition indexes as
theoretically that should be the fastest, but can only get either a Parallel
Seq Scan on each partition which is very slow, or a non pa
On Wed, Nov 7, 2018 at 2:46 PM Ondřej Bouda wrote:
> Hi,
>
> > 2) Is there any particular reason functions like that aren't built
> > into Postgres? They seem like they would be useful. (Or maybe I
> > missed them?)
>
> LEAST() and GREATEST() expressions do the same thing as yours smallest()
Hi,
> 2) Is there any particular reason functions like that aren't built
> into Postgres? They seem like they would be useful. (Or maybe I
> missed them?)
LEAST() and GREATEST() expressions do the same thing as yours smallest()
and largest(). See
https://www.postgresql.org/docs/current/funct
Hi. Building on the [type]_larger and _smaller functions (and lifting from
the documentation), I put together a couple of functions that will take any
number of arguments:
CREATE FUNCTION largest(VARIADIC anyarray) RETURNS anyelement AS $$
SELECT max($1[i]) FROM generate_subscripts($1, 1) g(i);
$
Andrew Gierth writes:
> [ nice summary ]
Should we try to improve the docs in this area?
regards, tom lane
> "David" == David Gauthier writes:
David> Tom: I seem to remember (but am probably wrong) that cursors
David> were locally scoped (or could be made so). This was several
David> years ago with an earlier v8 version. Was that sort of thing
David> around back then ?
There are two distinct
Ravi Krishna schrieb am 07.11.2018 um 15:10:
>
>> select data_page_checksum_version from pg_control_init()
>
> returned 1. So we have page_checksum turned on, and wal_log_hints off.
If page_checksum is enabled, then wal_log_hints is ignored (or actually always
assumed "on")
Thanks for the replies !
Steve: I don't remember using a recursive query like that, but it certainly
does look interesting.
Tom: I seem to remember (but am probably wrong) that cursors were locally
scoped (or could be made so). This was several years ago with an earlier
v8 version. Was that sor
> select data_page_checksum_version from pg_control_init()
returned 1. So we have page_checksum turned on, and wal_log_hints off.
> How to find out which parameter were used with initdb
pg_controldata -D | grep sum
...should give you something like:
Data page checksum version: 0
...and 0 means off.
Similarly, from SQL:
select data_page_checksum_version from pg_control_init()
Steve.
This email is confidential.
The best solution that I have found is kick all connections and execute a
select for update to /dev/null in the affected tables, i.e.:
psql -o /dev/null -c "select * from table for update" database
After this, the vacuum is executed w/o problems again.
Best regards,
Alexandre
Em qua, 7 de nov
On 11/5/18 5:41 PM, Adrien NAYRAT wrote:
We "solved" with a dump/restore on another server, also we kept previous
cluster to investigate. I want to be sure we encountered the bug solved
in 9.6.9 and it is not a new one.
FYI, I am not sure I will be able to keep previous cluster many days.
I
> As long as you don’t have page checksums turned on,
> you can prevent this by turning off wal_log_hints.
I did not run initdb. How to find out which parameter were used with initdb.
For page checksums
to be on, it must have been run with -k option.
Our wal_log_hints is left at default
Hi Guillaume,
Thanks for the update.
I found some script to implement this.
Regards,
Saikumar
From: Guillaume Lelarge
Date: Wednesday, 7 November 2018 at 5:05 PM
To: Saikumar
Cc: "pgsql-generallists.postgresql.org"
Subject: Re: Postgres 8.3 Grant all on database or schema
Hi,
Le mer. 7 nov.
Hi,
Le mer. 7 nov. 2018 à 09:59, Saikumar a écrit :
> Dear Sir,
>
>
>
> I am quite new the Postgre DB and working as DBA.
>
>
>
> I wanted to set the grant all permissions on the database to the role.
>
>
>
> Whatever the user assign to this role should inherits the same permissions
> on the dat
Dear Sir,
I am quite new the Postgre DB and working as DBA.
I wanted to set the grant all permissions on the database to the role.
Whatever the user assign to this role should inherits the same permissions on
the database tables. To achieve this scenarios, I have executed below steps.
Hello,
Can I skip function ResolveRecoveryConflictWithSnapshot if setting
hot_standby_feedback=on all the time?
As I know, function ResolveRecoveryConflictWithSnapshot is used for resolving
conflicts once master cleans dead tuples. But if I set hot_standby_feedback to
on, it will not appear co
Dne 3.11.2018 v 20:38 Tom Lane napsal(a):
Yeah, dump/reload would make the problem go away.
Same bug.
So we dumped and restored all our databases. After that, the crash on
DELETE never occurred (before, it was several times a day). However, the
crash on UPDATE still occurs on specific rows.
On 07-11-2018 08:52, Tony Shelver wrote:
Did you check the documentation for alter index?
https://www.postgresql.org/docs/10/sql-alterindex.html
You could create a script file (plenty of examples on the internet on
generating these) and then run through psql or whatever.
Also, if you just have
As long as you don’t have page checksums turned on, you can prevent this by
turning off wal_log_hints.
Steve.
This email is confidential. If you are not the intended recipient, please
advise us immediately and delete this message.
The registered name of Cantab- part of GAM Systematic is Cant
29 matches
Mail list logo
