ccing list
On 2023-09-27 00:12 +0200, dld write:
> On 26-09-2023 23:47, Erik Wienhold wrote:
> > On 2023-09-26 14:44 +0200, dld wrote:
> > > I followed the discussion about the schema resolution, and I really think
> > > there is need for an early bound (at function definition time) version of
> >
On 9/26/23 16:29, Adrian Klaver wrote:
[snip]
As a very simple example:
This is EXACTLY what I was looking for. Thank you.
create table source(id integer, fld_1 varchar);
insert into source values (1, 'cat'), (2, 'dog'), (3, 'fish');
CREATE OR REPLACE FUNCTION public.table_return(multipli
On Tue, Sep 26, 2023 at 5:33 PM Atul Kumar wrote:
> Hi,
>
> I have a query about parameters and log_statement
>
> my postgres version is 12 and running on centos 7
>
> my log_statement is set to "DDL".
>
> and log_min_duration_statement is set to "1ms"
>
> so technically it should log "ONLY DDLs
On 2023-09-26 14:44 +0200, dld wrote:
> I followed the discussion about the schema resolution, and I really think
> there is need for an early bound (at function definition time) version of
> CURRENT_SCHEMA (the first member of search_path)
You mean something like
CREATE FUNCTION myfunc()
On 9/26/23 13:29, Adrian Klaver wrote:
On 9/26/23 12:30, Ron wrote:
On 9/26/23 13:15, Tom Lane wrote:
Ron writes:
On 9/26/23 12:46, Tom Lane wrote:
I'm not really sure what functionality you think is missing from RETURNS
TABLE, granting that you do want to return a set of rows and not exac
On Tue, Sep 26, 2023, 12:34 Atul Kumar wrote:
> What am I missing here to understand, because as per my understanding
> log_statement and log_min_duration_statement are correlated, postgres
> should log according to log_statement parameter.
>
The two settings are independent. One logs *all* stat
On 9/26/23 12:30, Ron wrote:
On 9/26/23 13:15, Tom Lane wrote:
Ron writes:
On 9/26/23 12:46, Tom Lane wrote:
I'm not really sure what functionality you think is missing from RETURNS
TABLE, granting that you do want to return a set of rows and not exactly
one row.
There might be some other
On 9/26/23 13:15, Tom Lane wrote:
Ron writes:
On 9/26/23 12:46, Tom Lane wrote:
Ron writes:
Is there a way to define the SETOF record on the fly, like you do with
RETURNS TABLE (f1 type1, f2 type2)?
Doesn't RETURNS TABLE meet the need already?
That rationale means that RETURN SETOF is not
On 9/26/23 11:31 AM, Atul Kumar wrote:
Hi,
I have a query about parameters and log_statement
my postgres version is 12 and running on centos 7
my log_statement is set to "DDL".
and log_min_duration_statement is set to "1ms"
so technically it should log "ONLY DDLs" that take more than 1ms.
Hi,
I have a query about parameters and log_statement
my postgres version is 12 and running on centos 7
my log_statement is set to "DDL".
and log_min_duration_statement is set to "1ms"
so technically it should log "ONLY DDLs" that take more than 1ms.
but to my surprise, postgres is logging D
Hello all,
according to:
https://www.postgresql.org/docs/current/logical-replication-conflicts.html
or
https://www.postgresql.fastware.com/blog/addressing-replication-conflicts-using-alter-subscription-skip
The logfile is the _only_ place to find the transaction finish LSN that must be
s
Ron writes:
> On 9/26/23 12:46, Tom Lane wrote:
>> Ron writes:
>>> Is there a way to define the SETOF record on the fly, like you do with
>>> RETURNS TABLE (f1 type1, f2 type2)?
>> Doesn't RETURNS TABLE meet the need already?
> That rationale means that RETURN SETOF is not needed, and can be re
On 9/26/23 11:03 AM, Ron wrote:
On 9/26/23 12:46, Tom Lane wrote:
Ron writes:
Is there a way to define the SETOF record on the fly, like you do with
RETURNS TABLE (f1 type1, f2 type2)?
Doesn't RETURNS TABLE meet the need already?
That rationale means that RETURN SETOF is not needed, and ca
On 9/26/23 12:46, Tom Lane wrote:
Ron writes:
Is there a way to define the SETOF record on the fly, like you do with
RETURNS TABLE (f1 type1, f2 type2)?
Doesn't RETURNS TABLE meet the need already?
That rationale means that RETURN SETOF is not needed, and can be removed
from Pg, since "RETU
Ron writes:
> Is there a way to define the SETOF record on the fly, like you do with
> RETURNS TABLE (f1 type1, f2 type2)?
Doesn't RETURNS TABLE meet the need already?
regards, tom lane
Pg 9.6.24 (Yes, I know it's EOL.)
This simple "programming example" function works perfectly. However, it
requires me to create the TYPE "foo".
CREATE TYPE foo AS (tab_name TEXT, num_pages INT);
CREATE FUNCTION dba.blarge()
RETURNS SETOF foo
LANGUAGE plpgsql
AS
$$
DECLARE
Hi there!
I followed the discussion about the schema resolution, and I really
think there is need for an early bound (at function definition time)
version of CURRENT_SCHEMA (the first member of search_path)
Avoiding hard-coding of schema names, (and avoiding polluting the actual
users schema
Thank you.
On Sep 25, 2023, at 4:18 AM, Erik Wienhold wrote:
External Email
On 2023-09-22 17:37 +, Johnson, Bruce E - (bjohnson) wrote:
postgres=# pg_database_size(avi);
ERROR: syntax error at or near "pg_database_size"
LINE 1: pg_database_size(avi);
Call functions with SELECT, e.g.:
SEL
18 matches
Mail list logo
