2018-02-25 18:51 GMT+01:00 Lætitia Avrot :
> Hi all,
>
> For most beginners (and even a lot of advanced users) there is a strong
> confusion between simple VACUUM and VACUUM FULL. They think "full" is
> simply an option to the maintenance operation vacuum while it's not. It's a
> complete differe
2018-02-26 9:56 GMT+01:00 Lætitia Avrot :
> Although VACUUM and VACUUM FULL is different, then result is same (depends
>> on detail level) - the data files are optimized for other processing. You
>> should to see a VACUUM like family of commands that does some data files
>> optimizations. VACUUM,
Hi
2018-02-28 16:06 GMT+01:00 :
> n.zhuch...@postgrespro.ru писал 2018-02-28 18:04:
>
> Attached patch allow direct convertion of numeric types to bool like
>> integer::bool.
>> Supported types:
>> - smallint;
>> - bigint;
>> - real;
>> - double precision;
>> - decimal(numeric).
>>
>> This f
2018-02-28 16:13 GMT+01:00 Pavel Stehule :
> Hi
>
> 2018-02-28 16:06 GMT+01:00 :
>
>> n.zhuch...@postgrespro.ru писал 2018-02-28 18:04:
>>
>> Attached patch allow direct convertion of numeric types to bool like
>>> integer::bool.
>>> Supported ty
2018-03-01 5:51 GMT+01:00 Peter Eisentraut :
> This seems to be a popular issue when porting from PL/SQL, so I'll throw
> it out here for discussion. Apparently, in PL/SQL you can call another
> procedure without the CALL keyword. Here is a patch that attempts to
> implement that in PL/pgSQL as
2018-03-01 17:10 GMT+01:00 Daniel Verite :
> Fabien COELHO wrote:
>
> > Maybe some \csv command could set the format to csv, fieldsep to ",",
> > tuples_only to on, recordsep to '\n'? Not sure whether it would be
> > acceptable, though, and how to turn it off once turned on... Probably an
>
>
> - new plpgsql extra_checks
>
> WOA, but recently set to that status. Patch essentially from
> 2017-01-11.
>
> I'm not really sure there's agreement we want this.
>
>
This patch is simple and has benefit for users with basic plpgsql skills,
and some for all.
In more complex cases, proba
2018-03-01 23:10 GMT+01:00 Andres Freund :
> On 2018-01-23 17:08:56 +0100, Pavel Stehule wrote:
> > 2018-01-22 23:15 GMT+01:00 Stephen Frost :
> > > This really could use a new thread, imv. This thread is a year old and
> > > about a completely different feature than w
2018-03-02 3:38 GMT+01:00 Andres Freund :
> On 2018-03-02 03:13:04 +0100, Pavel Stehule wrote:
> > 2018-03-01 23:10 GMT+01:00 Andres Freund :
> >
> > > On 2018-01-23 17:08:56 +0100, Pavel Stehule wrote:
> > > > 2018-01-22 23:15 GMT+01:00 Stephen Frost :
&
2018-03-02 21:51 GMT+01:00 Tom Lane :
> Andres Freund writes:
> > On 2018-03-02 15:29:09 -0500, Bruce Momjian wrote:
> >> While I have heard people complain about how other databases cache
> >> prepare plans, I have heard few complaints about the Postgres approach,
> >> and I haven't even heard o
Hi
2018-03-01 21:14 GMT+01:00 David Steele :
> Hi Pavel,
>
> On 1/7/18 3:31 AM, Pavel Stehule wrote:
> >
> > There, now it's in the correct Waiting for Author state. :)
> >
> > thank you for comments. All should be fixed in attached patch
>
> Thi
2018-03-02 3:43 GMT+01:00 Pavel Stehule :
>
>
> 2018-03-02 3:38 GMT+01:00 Andres Freund :
>
>> On 2018-03-02 03:13:04 +0100, Pavel Stehule wrote:
>> > 2018-03-01 23:10 GMT+01:00 Andres Freund :
>> >
>> > > On 2018-01-23 17:08:56 +0100, Pavel St
2018-03-03 11:35 GMT+01:00 Fabien COELHO :
>
> Hello devs,
>
> This is a discussion without actual patch intended for pg12, to be added
> to CF 2018-09. The expected end result is either "returned with feedback",
> meaning proceed to send some big patch(es), or "rejected", meaning the
> project do
Hi
I am looking on project https://github.com/NikolayS/postgres_dba
Nice idea, and perfect publicity of typical PostgreSQL maintenance task.
We can allow to call some external applications on some key press (not
command) and evaluate their output. mc has F2 for User menu. It can works
well with
2018-03-03 15:02 GMT+01:00 Peter Eisentraut <
peter.eisentr...@2ndquadrant.com>:
> On 3/3/18 00:48, Tom Lane wrote:
> > I don't think that can possibly work. It would only be safe if, between
> > the thrower and the catcher, there were no other levels of control
> > operating according to the nor
2018-03-04 3:09 GMT+01:00 Craig Ringer :
> On 3 March 2018 at 17:56, Fabien COELHO wrote:
>
>>
>> The (trivial) big picture is to allow client-side expressions in psql
>> (which as a \if:-) by reusing pgbench expression engine, so that one could
>> write things like
>>
>> \let i :j + 12 * :k
>>
2018-03-04 8:29 GMT+01:00 Craig Ringer :
> On 4 March 2018 at 14:58, Pavel Stehule wrote:
>>
>>
>> 2018-03-04 3:09 GMT+01:00 Craig Ringer :
>>
>>> On 3 March 2018 at 17:56, Fabien COELHO wrote:
>>>
>>>>
>>>> The (trivial) big
2018-03-04 2:46 GMT+01:00 Tomas Vondra :
> On 03/02/2018 10:30 PM, Pavel Stehule wrote:
> > Hi
> >
> > 2018-03-01 21:14 GMT+01:00 David Steele > <mailto:da...@pgmasters.net>>:
> >
> > Hi Pavel,
> >
> > On 1/7/18 3:31 AM, Pavel Steh
Hi
I have to return back to 8bit encoding, and in this old world, the unicode
borders doesn't work. Sure. It can be simply disabled and forced to ascii.
What do you think about it?
Regards
Pavel
2018-03-04 16:53 GMT+01:00 Tom Lane :
> Pavel Stehule writes:
> > I have to return back to 8bit encoding, and in this old world, the
> unicode
> > borders doesn't work. Sure. It can be simply disabled and forced to
> ascii.
> > What do you think about it?
>
2018-03-04 13:37 GMT+01:00 Pavel Stehule :
>
>
> 2018-03-04 2:46 GMT+01:00 Tomas Vondra :
>
>> On 03/02/2018 10:30 PM, Pavel Stehule wrote:
>> > Hi
>> >
>> > 2018-03-01 21:14 GMT+01:00 David Steele > > <mailto:da...@pgmasters.net>>:
&g
Hi
Just curious
postgres=# explain analyze select array_upper(array_agg(i),1) from
generate_series(1,10) g(i);
QUERY
PLAN
2018-03-04 21:36 GMT+01:00 Tomas Vondra :
>
>
> On 03/04/2018 09:19 PM, Pavel Stehule wrote:
> > Hi
> >
> > Just curious
> >
> > postgres=# explain analyze select array_upper(array_agg(i),1)
Hi
I am looking on this patch. I found few issues:
1. compile warning
I../../src/include -D_GNU_SOURCE -I/usr/include/libxml2
-I/usr/lib64/perl5/CORE -c -o jsonb_plperl.o jsonb_plperl.c
jsonb_plperl.c: In function ‘SV_FromJsonbValue’:
jsonb_plperl.c:69:9: warning: ‘result’ may be used uninitia
Hi
2018-02-28 23:28 GMT+01:00 Peter Eisentraut <
peter.eisentr...@2ndquadrant.com>:
> This patch set adds support for INOUT parameters to procedures.
> Currently, INOUT and OUT parameters are not supported.
>
> A top-level CALL returns the output parameters as a result row. In
> PL/pgSQL, I have
2018-03-05 19:38 GMT+01:00 Peter Eisentraut <
peter.eisentr...@2ndquadrant.com>:
> On 3/5/18 11:00, Pavel Stehule wrote:
> > I am looking on attached code, and it looks pretty well. Can be really
> > nice if this code will be part of release 11, because it is very
>
2018-02-21 8:35 GMT+01:00 Michael Paquier :
> On Tue, Feb 20, 2018 at 06:46:57PM +0300, Arthur Zakirov wrote:
> > Just 2 cents from me. It seems that there is a problem with extensions
> > GUCs.
> >
> > [...]
> >
> > =# SELECT pg_get_functiondef('func_with_set_params'::regproc);
> > ERROR: unreco
2018-03-06 2:32 GMT+01:00 Michael Paquier :
> On Mon, Mar 05, 2018 at 09:25:09PM +0100, Pavel Stehule wrote:
> > I afraid so there is not good solution. Is possible to store options in
> > original form? When the function will be displayed, then the original
> value
> >
2018-03-05 19:41 GMT+01:00 Pavel Stehule :
>
>
> 2018-03-05 19:38 GMT+01:00 Peter Eisentraut com>:
>
>> On 3/5/18 11:00, Pavel Stehule wrote:
>> > I am looking on attached code, and it looks pretty well. Can be really
>> > nice if this code will be
2018-03-05 19:38 GMT+01:00 Peter Eisentraut <
peter.eisentr...@2ndquadrant.com>:
> On 3/5/18 11:00, Pavel Stehule wrote:
> > I am looking on attached code, and it looks pretty well. Can be really
> > nice if this code will be part of release 11, because it is very
>
2018-03-07 10:45 GMT+01:00 Fabien COELHO :
>
> Hello Daniel,
>
> Attached is a v2 fixing the bugs you mentioned, and adding ---csv/-C
>> as discussed upthread. I'll add some regression tests shortly.
>>
>
> Basically I'm waiting for the version with regression tests before
> reviewing.
>
> It is u
2018-03-07 12:55 GMT+01:00 Arthur Zakirov :
> On Wed, Mar 07, 2018 at 10:55:29AM +0100, Tomas Vondra wrote:
> > On 03/07/2018 09:55 AM, Arthur Zakirov wrote:
> > > Hello Andres,
> > >
> > > On Thu, Mar 01, 2018 at 08:31:49PM -0800, Andres Freund wrote:
> > >> Is there any chance we can instead can
2018-03-07 13:43 GMT+01:00 Arthur Zakirov :
> On Wed, Mar 07, 2018 at 01:02:07PM +0100, Pavel Stehule wrote:
> > > Understand. I'm not againts the mmap() approach, just I have lack of
> > > understanding mmap() benefits... Current shared Ispell approach
> requires
>
2018-03-07 13:58 GMT+01:00 Arthur Zakirov :
> On Wed, Mar 07, 2018 at 01:47:25PM +0100, Pavel Stehule wrote:
> > > Do you mean that a shared dictionary should be reloaded if its .affix
> > > and .dict files was changed? IMHO we can store last modification
> > > times
2018-03-07 14:10 GMT+01:00 Pavel Stehule :
>
>
> 2018-03-07 13:58 GMT+01:00 Arthur Zakirov :
>
>> On Wed, Mar 07, 2018 at 01:47:25PM +0100, Pavel Stehule wrote:
>> > > Do you mean that a shared dictionary should be reloaded if its .affix
>> > > and .dict
2018-03-07 19:40 GMT+01:00 Fabien COELHO :
>
> Hello Pavel,
>
> psql --csv 'TABLE Stuff;' > stuff.csv
>>>
>>
>> There is commad -c and it should be used. The --csv options should not to
>> have a parameter. I don't like a idea to have more options for query
>> execution.
>>
>
> Yes, I agre
2018-03-07 20:25 GMT+01:00 David Fetter :
> On Wed, Mar 07, 2018 at 08:04:05PM +0100, Fabien COELHO wrote:
> >
> > >> psql --csv -c 'TABLE foo' > foo.csv
> > >>
> > >>With a -c to introduce the command.
> > >
> > >This seems pretty specialized. If we're adding something new, how about
> > >
> >
2018-03-07 21:31 GMT+01:00 Daniel Verite :
> David Fetter wrote:
>
> > We have some inconsistency here in that fewer table formats are
> > supported, but I think asciidoc, etc., do this correctly via
> > invocations like:
> >
> >psql -P format=asciidoc -o foo.adoc -AtXc 'TABLE foo'
>
>
Hi
2018-03-08 1:53 GMT+01:00 Peter Eisentraut :
> On 3/6/18 04:22, Pavel Stehule wrote:
> > why just OUT variables are disallowed?
> >
> > The oracle initializes these values to NULL - we can do same?
>
> The problem is function call resolution. If we see a cal
2018-03-07 22:16 GMT+01:00 David Fetter :
> On Wed, Mar 07, 2018 at 09:37:26PM +0100, Pavel Stehule wrote:
> > 2018-03-07 21:31 GMT+01:00 Daniel Verite :
> >
> > > David Fetter wrote:
> > >
> > > > We have some inconsistency here in that few
2018-03-08 9:29 GMT+01:00 Fabien COELHO :
>
> I.e. really generate some csv from the data in just one option, not many.
>>>
>>> But this is obviously debatable.
>>>
>>
>> I suspect we'll get requests for an all-JSON option, HTML tables,
>> etc., assuming we don't have them already.
>>
>
> I would
2018-03-08 11:05 GMT+01:00 Fabien COELHO :
>
> Hello Daniel,
>
> PFA a v3 patch that implements that, along with regression tests this time.
>>
>
> My 0.02 €:
>
> Patch applies cleanly, compiles, make check ok, doc generation ok.
>
> I'm in favor of having a simple psql way to generate a convenien
2018-03-08 11:17 GMT+01:00 Pavel Stehule :
>
>
> 2018-03-08 11:05 GMT+01:00 Fabien COELHO :
>
>>
>> Hello Daniel,
>>
>> PFA a v3 patch that implements that, along with regression tests this
>>> time.
>>>
>>
>> My 0.02 €:
>&
2018-03-09 3:13 GMT+01:00 Peter Eisentraut :
> On 3/8/18 05:05, Fabien COELHO wrote:
> > I'm in favor of having a simple psql way to generate a convenient and
> > compliant CSV output for export/import.
>
> yes
>
> > I also think that a short option brings little value, and "--csv" is good
> > eno
2018-03-09 8:40 GMT+01:00 Fabien COELHO :
>
> About "fieldsep_csv", I do not like much the principle of having different
output variables to represent the same concept depending on the format. I
would rather have reused fieldsep as in your previous submission and set it
to "," when
Hi
Today, these task can be CPU limited . Do you think, so JIT can be used
there too?
Regards
Pavel
ions. But it is useless for LET command.
Regards
Pavel
>
> -
> Pavel Luzanov
> Postgres Professional: http://www.postgrespro.com
> The Russian Postgres Company
>
> On 08.03.2018 21:00, Pavel Stehule wrote:
>
> Hi
>
> 2018-02-07 7:34 GMT+01:00 Pavel Stehule :
&g
2018-03-12 9:08 GMT+01:00 Anthony Bykov :
> On Mon, 5 Mar 2018 14:03:37 +0100
> Pavel Stehule wrote:
>
> > Hi
> >
> > I am looking on this patch. I found few issues:
> >
> > 1. compile warning
> >
> > I../../src/include -D_GNU_SOURCE -I/usr
2018-03-12 16:38 GMT+01:00 Pavel Luzanov :
>
> On 12.03.2018 09:54, Pavel Stehule wrote:
>
>
> 2018-03-12 7:49 GMT+01:00 Pavel Luzanov :
>
>>
>> Is there any chances that it will work on replicas?
>>
> ...
>
> sure, it should to work. Now, I am try t
2018-03-13 14:14 GMT+01:00 Peter Eisentraut <
peter.eisentr...@2ndquadrant.com>:
> On 3/8/18 02:25, Pavel Stehule wrote:
> > It looks like some error in this concept. The rules for enabling
> > overwriting procedures should modified, so this collision should not be
> >
2018-03-13 10:54 GMT+01:00 Pavel Luzanov :
> Pavel Stehule wrote
> > Now, there is one important question - storage - Postgres stores all
> > objects to files - only memory storage is not designed yet. This is part,
> > where I need a help.
>
> O, I do not feel confide
2018-03-14 15:11 GMT+01:00 Alexander Korotkov :
> On Wed, Mar 14, 2018 at 2:10 AM, Andres Freund wrote:
>
>> On 2018-03-14 07:54:35 +0900, Michael Paquier wrote:
>> > On Tue, Mar 13, 2018 at 04:08:01PM +0300, Oleg Bartunov wrote:
>> > > The docs are here
>> > > https://github.com/obartunov/sqljso
JsonbIterators
>
> * passed JsonbParseState ** to XX_ToJsonbValue() functions.
>
> * fixed warnings (see below)
>
> * fixed comments (see below)
>
>
> Also I am not sure if we need to use newRV() for returning SVs in
> Jsonb_ToSV() and JsonbValue_ToSV().
>
>
Hi
create or replace procedure proc2(in a int, in b int)
as $$
begin
a := a * 10;
b := b * 10;
end;
$$ language plpgsql;
postgres=# call proc2(a => 10,b => 20);
ERROR: XX000: unrecognized node type: 107
LOCATION: ExecInitExprRec, execExpr.c:2114
Regards
Pavel
Hi
2018-03-16 2:57 GMT+01:00 Peter Eisentraut :
> On 2/28/18 14:51, Peter Eisentraut wrote:
> > So far, a nested CALL or DO in PL/pgSQL would not establish a context
> > where transaction control statements were allowed. This patch fixes
> > that by handling CALL and DO specially in PL/pgSQL, pa
Hi
I finished my work on pspg pager - a special pager designed for usage
together with psql (but other databases, other TUI clients are supported
too).
I is available from source code https://github.com/okbob/pspg
or from packages
Regards
Pavel
2018-03-16 2:46 GMT+01:00 Tomas Vondra :
> On 03/04/2018 07:07 PM, Pavel Stehule wrote:
> >
> > ...
> >
> > I am sending updated patch with Tomas changes
> >
>
> Seems 2cf8c7aa48 broke this patch, as it tweaked a number of regression
> tests. Other t
2018-03-15 22:13 GMT+01:00 Pavel Stehule :
> Hi
>
> create or replace procedure proc2(in a int, in b int)
> as $$
> begin
> a := a * 10;
> b := b * 10;
> end;
> $$ language plpgsql;
>
> postgres=# call proc2(a => 10,b => 20);
> ERROR: XX0
2018-03-16 5:46 GMT+01:00 Michael Paquier :
> On Fri, Mar 16, 2018 at 10:25:35AM +0900, Michael Paquier wrote:
> >> But, I suppose it is a bit too big.
> >
> > That's of course not backpatchable.
>
> So in this jungle attached is my counter-proposal. As the same code
> pattern is repeated in thre
2018-03-16 9:34 GMT+01:00 Kyotaro HORIGUCHI :
> At Fri, 16 Mar 2018 09:16:54 +0100, Pavel Stehule
> wrote in zyujawdnu...@mail.gmail.com>
> > 2018-03-16 5:46 GMT+01:00 Michael Paquier :
> >
> > > On Fri, Mar 16, 2018 at 10:25:35AM +0900, Michael Paquier wrote:
&
2018-03-16 8:43 GMT+01:00 Pavel Stehule :
>
>
> 2018-03-15 22:13 GMT+01:00 Pavel Stehule :
>
>> Hi
>>
>> create or replace procedure proc2(in a int, in b int)
>> as $$
>> begin
>> a := a * 10;
>> b := b * 10;
>> end;
>>
2018-03-16 11:29 GMT+01:00 Pavel Stehule :
>
>
> 2018-03-16 8:43 GMT+01:00 Pavel Stehule :
>
>>
>>
>> 2018-03-15 22:13 GMT+01:00 Pavel Stehule :
>>
>>> Hi
>>>
>>> create or replace procedure proc2(in a int, in b int)
&g
2018-03-16 18:35 GMT+01:00 Peter Eisentraut <
peter.eisentr...@2ndquadrant.com>:
> On 3/16/18 00:24, Pavel Stehule wrote:
> > What is benefit of DO command in PLpgSQL? Looks bizarre for me.
>
> Not very typical, but we apply the same execution context handling to
> CALL
2018-03-16 18:49 GMT+01:00 Tom Lane :
> Pavel Stehule writes:
> > 2018-03-16 18:35 GMT+01:00 Peter Eisentraut <
> > peter.eisentr...@2ndquadrant.com>:
> >> Not very typical, but we apply the same execution context handling to
> >> CALL and DO at the
2018-03-19 21:47 GMT+01:00 Tomas Vondra :
> Hi,
>
> I'm looking at the updated patch (plpgsql-extra-check-180316.patch), and
> this time it applies and builds OK. The one thing I noticed is that the
> documentation still uses the old wording for strict_multi_assignement:
>
> WARNING: Number of ev
Hi
I have a talk with Alex Stanev about known issue that block indexes - bad
param types
postgres=# do $$
declare _id numeric = 22;
begin
perform * from bigtable where a = _id;
end;
$$;
DO
Time: 108,775 ms
postgres=# do $$
declare _id numeric = 22;
begin
perform * from bigtable where
2018-03-20 15:05 GMT+01:00 Merlin Moncure :
> On Wed, Feb 28, 2018 at 4:28 PM, Peter Eisentraut
> wrote:
> > This patch set adds support for INOUT parameters to procedures.
> > Currently, INOUT and OUT parameters are not supported.
> >
> > A top-level CALL returns the output parameters as a resul
2018-03-20 15:18 GMT+01:00 Merlin Moncure :
> On Tue, Mar 20, 2018 at 9:09 AM, Pavel Stehule
> wrote:
> >> Edit: In one case, after dropping the function and recreating it, I
> >> got the procedure to return 0 where it had not before, so this smells
> >> l
2018-03-20 13:56 GMT+01:00 Tels :
> Hello Pavel and Tomas,
>
> On Tue, March 20, 2018 12:36 am, Pavel Stehule wrote:
> > 2018-03-19 21:47 GMT+01:00 Tomas Vondra :
> >
> >> Hi,
> >>
> >> I'm looking at the updated patch (plpgsql-extra-check-1803
2018-03-20 17:31 GMT+01:00 Peter Eisentraut <
peter.eisentr...@2ndquadrant.com>:
> On 3/16/18 06:29, Pavel Stehule wrote:
> > attached patch fixes it
>
> The fix doesn't seem to work for LANGUAGE SQL procedures. For example:
>
> CREATE PROCEDURE ptest5(a int, b in
Hi
I have reported very memory expensive pattern:
CREATE OR REPLACE FUNCTION public.fx(iter integer)
RETURNS void
LANGUAGE plpgsql
AS $function$
declare
c cursor(m bigint) for select distinct i from generate_series(1, m) g(i);
t bigint;
s bigint;
begin
for i in 1..iter
loop
open c
pá 12. 1. 2024 v 10:27 odesílatel Pavel Stehule
napsal:
> Hi
>
> I have reported very memory expensive pattern:
>
> CREATE OR REPLACE FUNCTION public.fx(iter integer)
> RETURNS void
> LANGUAGE plpgsql
> AS $function$
> declare
> c cursor(m bigint) for select dis
pá 12. 1. 2024 v 11:54 odesílatel Michael Banck napsal:
> Hi,
>
> On Fri, Jan 12, 2024 at 11:02:14AM +0100, Pavel Stehule wrote:
> > pá 12. 1. 2024 v 10:27 odesílatel Pavel Stehule >
> > napsal:
> >
> > > Hi
> > >
> > > I have reported v
pá 12. 1. 2024 v 14:53 odesílatel Michael Banck napsal:
> Hi,
>
> On Fri, Jan 12, 2024 at 01:35:24PM +0100, Pavel Stehule wrote:
> > pá 12. 1. 2024 v 11:54 odesílatel Michael Banck napsal:
> > > Which version of Postgres is this and on which platform/distribution?
Hi
pá 12. 1. 2024 v 22:25 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > default master branch - res 190MB ram
> > jit_inline_above_cost = -1 doesn't helps
> > disabling JIT doesn't helps too,
>
> > so it looks like the wrong hypothesis , and t
Hi
po 15. 1. 2024 v 7:24 odesílatel Kirk Wolak napsal:
> Daniel,
> You have a commit [1] that MIGHT fix this.
> I have a script that recreates the problem, using random data in pg_temp.
> And a nested cursor.
>
> It took me a few days to reduce this from actual code that was
> experiencing t
po 15. 1. 2024 v 15:03 odesílatel Daniel Gustafsson
napsal:
> > On 15 Jan 2024, at 07:24, Kirk Wolak wrote:
>
> > You have a commit [1] that MIGHT fix this.
> > I have a script that recreates the problem, using random data in pg_temp.
> > And a nested cursor.
>
> Running your reproducer script
čt 18. 1. 2024 v 8:59 odesílatel Alexander Korotkov
napsal:
> On Thu, Jan 18, 2024 at 4:16 AM torikoshia
> wrote:
> > On 2024-01-18 10:10, jian he wrote:
> > > On Thu, Jan 18, 2024 at 8:57 AM Masahiko Sawada >
> > > wrote:
> > >> On Thu, Jan 18, 2024 at 6:38 AM Tom Lane wrote:
> > >> > Kyotaro
Hi
I starting work on this patch - start with rebase
Regards
Pavel
From c7bbdd67898b397143fa314152f32d5ca935c082 Mon Sep 17 00:00:00 2001
From: "ok...@github.com"
Date: Sun, 21 Jan 2024 14:23:06 +0100
Subject: [PATCH 1/4] Protocol ReportGUC message
This patch implements dynamic reporting chang
Hi
po 22. 1. 2024 v 16:06 odesílatel Christoph Berg napsal:
> Assuming a SELECT statement reading from a single table, it is quite an
> effort to transform that statement to an UPDATE statement on that table,
> perhaps to fix a typo that the user has spotted in the query result.
>
> First, the g
po 22. 1. 2024 v 17:34 odesílatel David G. Johnston <
david.g.johns...@gmail.com> napsal:
> On Mon, Jan 22, 2024 at 8:06 AM Christoph Berg wrote:
>
>> Assuming a SELECT statement reading from a single table, it is quite an
>> effort to transform that statement to an UPDATE statement on that table
po 22. 1. 2024 v 23:54 odesílatel Christoph Berg napsal:
> Re: David G. Johnston
> > Building off the other comments, I'd suggest trying to get rid of the
> > intermediate JSOn format and also just focus on a single row at any given
> > time.
>
> We need *some* machine-readable format. It doesn't
út 23. 1. 2024 v 11:38 odesílatel Christoph Berg napsal:
> Re: Pavel Stehule
> > It looks great for simple queries, but if somebody uses it like SELECT *
> > FROM pg_proc \gedit
>
> What's wrong with that? If the pager can handle the amount of data,
> the editor can
Hi
čt 11. 1. 2024 v 12:12 odesílatel Jelte Fennema-Nio
napsal:
> On Tue, 12 Sept 2023 at 09:46, Peter Eisentraut
> wrote:
> > ISTM that for a purpose like pgbouncer, it would be simpler to add a new
> > GUC "report these variables" and send that in the startup message? That
> > might not help
út 12. 9. 2023 v 9:46 odesílatel Peter Eisentraut
napsal:
> On 11.09.23 13:59, Jelte Fennema wrote:
> > @Tom and @Robert, since you originally suggested extending the
> > protocol for this, I think some input from you on the protocol design
> > would be quite helpful. BTW, this protocol extension
po 8. 1. 2024 v 6:08 odesílatel vignesh C napsal:
> On Tue, 12 Sept 2023 at 14:39, Peter Eisentraut
> wrote:
> >
> > On 11.09.23 13:59, Jelte Fennema wrote:
> > > @Tom and @Robert, since you originally suggested extending the
> > > protocol for this, I think some input from you on the protocol d
Hi
pá 26. 1. 2024 v 11:39 odesílatel Kurlaev Jaroslav
napsal:
> Hi hackers,
>
> I'm not sure if it's the best list for my question but I have a following
> problem.
>
> I have an existing DB with lots of data and I need to modify the behavior
> of one specific
> built-in function. I can of cours
Hi
pá 26. 1. 2024 v 19:41 odesílatel Steve Chavez napsal:
> Hello hackers,
>
> Currently a function definition must include its body inline. Because of
> this, when storing function definitions in files, linters and syntax
> highlighters for non-SQL languages (python, perl, tcl, etc) won't work.
pá 26. 1. 2024 v 20:45 odesílatel napsal:
> Pavel Stehule:
> > looks a little bit obscure - why do you need to do it from psql? And how
> > frequently do you do it?
>
> I store all my SQL code in git and use "psql -e" to "bundle" it into an
> ext
pá 26. 1. 2024 v 21:04 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > but why you need to do in psql? - you can prepare content outside and
> > execute just like echo "CREATE FUNCTION " | psql
>
> The bit that's probably hard if you're
pá 26. 1. 2024 v 21:17 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > I don't know, maybe I have a problem with the described use case. I
> cannot
> > imagine holding the body and head of PL routines in different places and
> I
> > don't unders
pá 26. 1. 2024 v 11:40 odesílatel Jelte Fennema-Nio
napsal:
> On Thu, 25 Jan 2024 at 21:43, Pavel Stehule
> wrote:
> > 2. using GUC for all reported GUC looks not too readable. Maybe it
> should be used just for customized reporting, not for default
>
> I thought about thi
so 27. 1. 2024 v 0:04 odesílatel Jelte Fennema-Nio
napsal:
> On Fri, 26 Jan 2024 at 21:35, Pavel Stehule
> wrote:
> > I see a possibility of disabling reporting as possibly dangerous.
> Without reporting encoding you can break psql. So it should be limited just
> to few val
so 27. 1. 2024 v 10:24 odesílatel Jelte Fennema-Nio
napsal:
> On Sat, 27 Jan 2024 at 08:35, Pavel Stehule
> wrote:
> > Until now, it is not possible to disable reporting. So clients can
> expect so reporting is workable.
>
> Sure, so if we leave the default as is that&#
ne 28. 1. 2024 v 10:42 odesílatel Jelte Fennema-Nio
napsal:
> On Sat, 27 Jan 2024 at 20:44, Pavel Stehule
> wrote:
> > client_encoding, standard_conforming_strings, server_version,
> default_transaction_read_only, in_hot_standby and scram_iterations
> > are used by libpq d
ne 28. 1. 2024 v 19:00 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> Thanks for the update, smaller patches looks promising.
>
> Off the list Pavel has mentioned that the first two patches contain a
> bare minimum for session variables, so I've reviewed them once more and
> suggest to
ne 28. 1. 2024 v 22:52 odesílatel Jelte Fennema-Nio
napsal:
> On Sun, 28 Jan 2024 at 20:01, Pavel Stehule
> wrote:
> > There is another reason - compatibility with other drivers. We maintain
> just libpq, but there are JDBC, Npgsql, and some native Python drivers. I
> didn&#x
text AS :/absolute/path/contents.py language
> plpython3u;
>
> Any thoughts?
>
has sense
Pavel
>
> Best regards,
> Steve Chavez
>
> On Mon, 29 Jan 2024 at 08:42, Andrew Dunstan wrote:
>
>>
>> On 2024-01-26 Fr 15:17, Tom Lane wrote:
>> > Pavel Steh
po 29. 1. 2024 v 18:11 odesílatel Tom Lane napsal:
> Steve Chavez writes:
> > However, :{?variable_name} is already taken by psql to test whether a
> > variable is defined or not. It might be confusing to use the same syntax.
>
> Hmm. Maybe we could go with :{+...} or the like?
>
> > How about
po 29. 1. 2024 v 19:36 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Mon, Jan 29, 2024 at 08:57:42AM +0100, Pavel Stehule wrote:
> > Hi
> >
> > ne 28. 1. 2024 v 19:00 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
> > napsal:
> &
901 - 1000 of 2495 matches
Mail list logo
