2018-03-22 19:28 GMT+01:00 Pavel Stehule :
>
>
> 2018-03-22 18:38 GMT+01:00 Fabien COELHO :
>
>>
>> Hello Pavel,
>>
>> Using \pset format csv means overwriting field sep every time - nobody
>>> uses
>>> |
>>>
>>
>> Yep.
2018-03-22 20:10 GMT+01:00 Pavel Stehule :
>
>
> 2018-03-22 19:28 GMT+01:00 Pavel Stehule :
>
>>
>>
>> 2018-03-22 18:38 GMT+01:00 Fabien COELHO :
>>
>>>
>>> Hello Pavel,
>>>
>>> Using \pset format csv means overwrit
2018-03-21 6:24 GMT+01:00 Pavel Stehule :
>
>
> 2018-03-20 18:38 GMT+01:00 Pavel Stehule :
>
>> Hi
>>
>> I am sending new update. The code is less ugly, and the current
>> functionality is +/- final for first stage. It should be good enough for
>> playi
2018-03-23 12:59 GMT+01:00 Daniel Verite :
> Pavel Stehule wrote:
>
> > It should not be hard. All formats can has '|' like now, and csv can
> have a
> > ',' - then if field separator is not explicit, then default field
> separator
> &g
2018-03-23 18:55 GMT+01:00 Fabien COELHO :
>
> Hello Daniel,
>
> Do you know when you'll have an updated patch that addresses the minor
>>> issues brought up in review and the concern above?
>>>
>>
>> Here's an update addressing the issues discussed:
>>
>> - fieldsep and recordsep are used, no mor
2018-03-24 8:15 GMT+01:00 Fabien COELHO :
>
> Hello Pavel,
>
> The patch adds a simple way to generate csv output from "psql" queries,
>>> much simpler than playing around with COPY or \copy. It allows to
>>> generate
>>> a clean CSV dump from something as short as:
>>>
>>> sh> psql --csv -c 'TA
2018-03-24 8:24 GMT+01:00 Pavel Stehule :
>
>
> 2018-03-24 8:15 GMT+01:00 Fabien COELHO :
>
>>
>> Hello Pavel,
>>
>> The patch adds a simple way to generate csv output from "psql" queries,
>>>> much simpler than playing around with COPY
minor fix
>
all is working now
[pavel@nemesis postgresql]$ psql --csv -F ';' -c "table foo" postgres
a;b;c
3;4;Nazdar
3;4;Nazdar
[pavel@nemesis postgresql]$ psql -F ';' --csv -c "table foo" postgres
a;b;c
3;4;Nazdar
3;4;Nazdar
[pavel@nemesis postgresql]$ psql --csv -c "table foo" postgres
a,
minor fix
>
>
another fix in help
Pavel
postgres=# \f
Field separator is "".
postgres=# \pset format csv
Output format is csv.
postgres=# \f
Field separator is ",".
postgres=# \pset format unaligned
Output format is unaligned.
postgres=# \f
Field separator is "|".
postgres=# \f ;
Field separator
2018-03-24 10:06 GMT+01:00 Fabien COELHO :
>
> Hello Pavel,
>
> I'm suggesting to add \csv which would behave like \H to toggle CSV
mode so as to improve this situation, with a caveat which is that
toggling back \csv would have forgotted the previous settings (just
l
2018-03-25 15:21 GMT+02:00 Fabien COELHO :
>
>
> Hello Pavel,
>
> [...]
>>>
>> it is correct. Default format is aligned, that doesn't use fieldsep.
>>
>
> My comment is that currently fieldsep is kind of a variable, the value of
> which is displayed and reliable wrt commands executed afterwards, a
2018-03-25 18:02 GMT+02:00 Pavel Stehule :
>
>
> 2018-03-25 15:21 GMT+02:00 Fabien COELHO :
>
>>
>>
>> Hello Pavel,
>>
>> [...]
>>>>
>>> it is correct. Default format is aligned, that doesn't use fieldsep.
>>>
&g
2018-03-26 14:44 GMT+02:00 Daniel Verite :
> Pavel Stehule wrote:
>
> > implemented in attached patch
>
> Consider your initial output of \pset, when no option is specified
> =
> $ ./psql
> psql (11devel)
> Type "help"
2018-03-26 20:26 GMT+02:00 Daniel Verite :
> Pavel Stehule wrote:
>
> > b) the list of pset options is bloating - every possible new format can
> > introduce fieldsep_X option
>
> What new format?
> The usefulness of fieldsep does not extend outside of xSV,
2018-03-27 2:44 GMT+02:00 Nikolay Samokhvalov :
> On Sat, Mar 3, 2018 at 1:08 PM, Pavel Stehule
> wrote:
>
>> Hi
>>
>
> Hi Pavel, I don't know how I missed this email, but finally I found it :-)
>
>
>> I am looking on project https://github.com/Nikola
2018-03-27 11:35 GMT+02:00 Fabien COELHO :
>
> Hello Pavel,
>
> I'd like to convince you to compromise, because otherwise I'm afraid we
> will not get this feature.
>
> 1. use special default string for formats that doesn't field sep - like
>>>
"not used" or some
2. I can implemet the op
2018-03-28 10:24 GMT+02:00 Fabien COELHO :
>
> Hello Pavel,
>
> I'd like to convince you to compromise, because otherwise I'm afraid we
>>> will not get this feature.
>>>
>>
>> [...]
>>
>>>
>>> The only no-surprise, no-behavioral-change, alternative I see is to have
>>> a
>>> csv-specific fieldsep
2018-03-29 14:17 GMT+02:00 Daniel Verite :
> David G. Johnston wrote:
>
> > Or, really, just make --csv take an optional argument which, if present,
> is
> > the delimiter.
>
> I don't think psql can support optional arguments because
> psql --option foo
> would be ambiguous, since foo cou
2018-03-29 16:07 GMT+02:00 Bruce Momjian :
> On Fri, Mar 2, 2018 at 12:13:26PM -0800, Peter Geoghegan wrote:
> > FWIW, I think that pgbench would become a lot more usable if someone
> > maintained a toolset for managing pgbench. Something similar to Greg
> > Smith's pgbench-tools project, but wit
2018-03-30 0:15 GMT+02:00 David G. Johnston :
> On Thu, Mar 29, 2018 at 7:30 AM, Daniel Verite
> wrote:
>
>> Personally I think the benefit of sharing fieldsep is not worth these
>> problems, but I'm waiting for the discussion to continue with
>> more opinions.
>
>
> Apologies in advance if I mi
Hi
CREATE OR REPLACE PROCEDURE public.proc(a integer, INOUT b integer, c
integer)
LANGUAGE plpgsql
AS $procedure$
begin
b := a + c;
end;
$procedure$
CREATE OR REPLACE PROCEDURE public.testproc()
LANGUAGE plpgsql
AS $procedure$
declare r int;
begin
call proc(10, r, 20);
end;
$procedure$
pos
2018-04-01 8:30 GMT+02:00 Fabien COELHO :
>
> Hello Isaac,
>
> Personnaly I do not have any problem with CSV defaulting to '|' separator,
>>> given that anyway people often use anything but a comma for the purpose,
>>> including '|'.
>>>
>>> However Pavel wants to block the patch on this point. To
2018-04-01 1:00 GMT+02:00 Tomas Vondra :
>
>
> On 03/31/2018 08:28 PM, Tomas Vondra wrote:
> >
> >
> > On 03/31/2018 07:56 PM, Tomas Vondra wrote:
> >> On 03/31/2018 07:38 PM, Pavel Stehule wrote:
> >>> Hi
> >>>
> >>&g
Hi
small bugfix patch
Regards
Pavel
diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c
index 6926ca132e..f6f7c52bb0 100644
--- a/src/bin/psql/tab-complete.c
+++ b/src/bin/psql/tab-complete.c
@@ -3685,7 +3685,7 @@ psql_completion(const char *text, int start, int end)
COMPLE
2018-04-06 5:46 GMT+02:00 Jonathan S. Katz :
>
> > On Apr 5, 2018, at 11:08 PM, Peter Eisentraut <
> peter.eisentr...@2ndquadrant.com> wrote:
> >
> > On 4/1/18 03:27, Pavel Stehule wrote:
> >> I don't share option so CSV format should be exactly s
2018-04-05 21:01 GMT+02:00 Peter Eisentraut <
peter.eisentr...@2ndquadrant.com>:
> On 4/4/18 14:03, Tomas Vondra wrote:
> >> If there's really no other way, you could use a PG_TRY block to
> >> ensure that the pointer gets reset on the way out. But I question
> >> why we've got a design that requi
2018-04-06 8:21 GMT+02:00 Ashutosh Bapat :
> On Tue, Apr 3, 2018 at 10:48 AM, Ashutosh Bapat
> wrote:
> >>
> >> Why is this done appropriately at ExecInitExpr() time, rather than at
> >> plan time? Seems like eval_const_expressions() would be a bit more
> >> appropriate (being badly named aside..
2018-04-07 13:55 GMT+02:00 Daniel Verite :
> Pavel Stehule wrote:
>
> > so we can to have
> >
> > \pset format xxx
> >
> > and set of local possibly changed defaults
> >
> > \pset csv_fieldsep ,
> > \pset csv_tuplesonly on
> > \
2018-04-07 14:23 GMT+02:00 Daniel Verite :
> Peter Eisentraut wrote:
>
> > Another thought: Isn't CSV just the same as unaligned output plus some
> > quoting? Could we add a quote character setting and then define --csv
> > to be quote-character = " and fieldsep = , ?
>
> Plus footer set
2018-04-14 15:58 GMT+02:00 Peter Eisentraut <
peter.eisentr...@2ndquadrant.com>:
> On 3/22/18 10:19, Pavel Stehule wrote:
> > attached patch should to fix it
>
> Committed.
>
Thank you
Pavel
>
> I had to make a small tweak to make INOUT + DEFAULT parameters work
Hi
I am testing PostgreSQL in customer's environment and I found some
unexpected behave.
When auto_explain is used, and there is slower parallel query, then
auto_explain raises log for any slow process.
arallel worker for PID 20089 : auto_explain database=NULL client=local
appname=psql
arall
2018-04-16 10:33 GMT+02:00 Tomas Vondra :
>
>
> On 04/16/2018 09:25 AM, Pavel Stehule wrote:
> > Hi
> >
> > I am testing PostgreSQL in customer's environment and I found some
> > unexpected behave.
> >
> > When auto_explain is used, and there is s
Hi,
my customer does performance checks of PostgreSQL 9.5 and 10. Almost all
queries on 10 are faster, but there are few queries (40 from 1000) where
PostgreSQL 9.5 is significantly faster than. Unfortunately - pretty fast
queries (about 20ms) are too slow now (5 sec).
attached execution plans
I
2018-04-16 14:00 GMT+02:00 Tomas Vondra :
>
>
> On 04/16/2018 11:34 AM, Pavel Stehule wrote:
> > Hi,
> >
> > my customer does performance checks of PostgreSQL 9.5 and 10. Almost all
> > queries on 10 are faster, but there are few queries (40 from 1000) where
&g
2018-04-16 15:52 GMT+02:00 Tomas Vondra :
> > Query Performs nicely, but no parallel workers are used:
> > GroupAggregate (cost=2611148.87..2611152.89 rows=31 width=22) (actual
> > time=0.084..0.084 rows=0 loops=1)
> >Group Key:
> > f_zendesktickets_aaeljtllr5at3el.cstm_custom_38746665_primar
Hi
2018-04-17 16:14 GMT+02:00 Arthur Zakirov :
> Hello Pavel,
>
> On Thu, Oct 26, 2017 at 09:21:24AM +0200, Pavel Stehule wrote:
> > I hope so this proposal is good enough and simple.
> >
> > Comments, notes?
>
> As I understood variables are stored in pg_class
2018-04-19 5:01 GMT+02:00 Kyotaro HORIGUCHI :
> At Mon, 16 Apr 2018 18:39:24 +0530, Ashutosh Bapat <
> ashutosh.ba...@enterprisedb.com> wrote in fg2sub360mg3cbxq1...@mail.gmail.com>
> > On Mon, Apr 16, 2018 at 4:10 PM, Martin Swiech
> wrote:
> > > Hi folks,
> > >
> > > I got some complex query w
2018-04-19 21:56 GMT+02:00 Alvaro Herrera :
> Michael Paquier wrote:
>
> > Then, let's consider the beginning of the first commit fest of v12 as
> > judgement. Implementing radix tree for shared buffers is a long-term
> > project, which has no guarantee to get merged, while a visibly-simple
> > r
Hi
I searching a reason why result of plpgsql_check's regress tests are
different when its executed from regress tests or interactive.
This is simple test
drop table testtable;
create table testtable(a int, b int);
create or replace function test()
returns int as $$
declare r testtable;
begin
2018-04-20 17:32 GMT+02:00 Robert Haas :
> On Tue, Apr 17, 2018 at 12:28 PM, Pavel Stehule
> wrote:
> > It true, so there are lot of "unused" attributes for this purpose, but
> there
> > is lot of shared attributes, and lot of shared code. Semantically, I see
>
2018-04-20 15:44 GMT+02:00 Tom Lane :
> Pavel Stehule writes:
> > In interactive mode, the build_row_from_class has unrefreshed metadata.
> But
> > why this behave I see only in psql and not in my regress tests?
>
> The short answer is that no plpgsql version before comm
Hi
I am plpgsql_check author and now, I am solving bug related to cached
plpgsql function. I am not able fore plpgsql compilation - and sometimes
the compiled version can be obsolete. As protection to false alarms, I need
fresh compilation immediately before plpgsql_check call.
I need a new optio
Hi
2018-04-24 9:58 GMT+02:00 Pierre Ducroquet
:
> Hi
>
> When running database migrations with .sql files on a live database, it's
> not
> uncommon to have to run a migration in a loop to prevent a big lock on a
> table.
> For instance if one want to delete some old datas from a big table one
>
čt 5. 9. 2019 v 8:39 odesílatel Quan Zongliang <
zongliang.q...@postgresdata.com> napsal:
> Dear hackers,
>
> I found that such a statement would get 0 in PL/pgSQL.
>
> PREPARE smt_del(int) AS DELETE FROM t1;
> EXECUTE 'EXECUTE smt_del(100)';
> GET DIAGNOSTICS j = ROW_COUNT;
>
> In fact, this is a
čt 5. 9. 2019 v 10:57 odesílatel Quan Zongliang <
zongliang.q...@postgresdata.com> napsal:
> On 2019/9/5 16:31, Pavel Stehule wrote:
> >
> >
> > čt 5. 9. 2019 v 10:25 odesílatel Quan Zongliang
> > > <mailto:zongliang.q...@postgresdata.com>> napsal:
čt 5. 9. 2019 v 10:25 odesílatel Quan Zongliang <
zongliang.q...@postgresdata.com> napsal:
> On 2019/9/5 15:09, Pavel Stehule wrote:
> >
> >
> > čt 5. 9. 2019 v 8:39 odesílatel Quan Zongliang
> > > <mailto:zongliang.q...@postgresdata.com>> napsal:
pá 6. 9. 2019 v 3:36 odesílatel Quan Zongliang <
zongliang.q...@postgresdata.com> napsal:
> On 2019/9/5 17:33, Pavel Stehule wrote:
> >
> >
> > čt 5. 9. 2019 v 10:57 odesílatel Quan Zongliang
> > > <mailto:zongliang.q...@postgresdata.com>> napsal:
Hi
When I played with vertical cursor support I got badly displayed last
columns when border was not 2. Only when border is 2, then psql displays
last column with same width for each row.
I think so we can force column width alignment for any border styles today
(for alignment and wrapping styles
Hi
create table omega(a int);
create view omega_view as select * from omega;
insert into omega values(10);
postgres=# select table_type, table_name from information_schema.tables
where table_name like 'omega%';
┌┬┐
│ table_type │ table_name │
╞╪╡
│
st 11. 9. 2019 v 7:45 odesílatel Amit Kapila
napsal:
> On Sun, Sep 1, 2019 at 9:09 AM Amit Kapila
> wrote:
> >
> > The current example shows the usage of looping in plpgsql, so as such
> > there is no correctness issue, but OTOH there is no harm in updating
> > the example as proposed by Ian Bar
st 11. 9. 2019 v 9:49 odesílatel Erik Rijkers napsal:
> On 2019-09-11 08:14, Pavel Stehule wrote:
> > Hi
> >
> > [matviews not showing up in information_schema.tables]
> >
> > Is it expected behave? Tested on master branch.
>
> I think it is; it has been
st 11. 9. 2019 v 10:52 odesílatel Juan José Santamaría Flecha <
juanjo.santama...@gmail.com> napsal:
> On Wed, Sep 11, 2019 at 10:03 AM Pavel Stehule
> wrote:
> >
> > st 11. 9. 2019 v 9:49 odesílatel Erik Rijkers napsal:
> >>
> >> On 2019-0
st 11. 9. 2019 v 11:51 odesílatel Amit Kapila
napsal:
> On Wed, Sep 11, 2019 at 11:40 AM Pavel Stehule
> wrote:
> >
> > st 11. 9. 2019 v 7:45 odesílatel Amit Kapila
> napsal:
> >>
> >> On Sun, Sep 1, 2019 at 9:09 AM Amit Kapila
> wrote:
> >&
pá 13. 9. 2019 v 9:09 odesílatel Konstantin Knizhnik <
k.knizh...@postgrespro.ru> napsal:
>
>
> On 24.08.2019 19:13, Pavel Stehule wrote:
>
>
>
> so 24. 8. 2019 v 18:01 odesílatel David Fetter napsal:
>
>> On Fri, Aug 23, 2019 at 11:10:28AM +0200, Pavel Stehul
čt 12. 9. 2019 v 0:01 odesílatel Alvaro Herrera from 2ndQuadrant <
alvhe...@alvh.no-ip.org> napsal:
> On 2019-Jul-31, Rafia Sabih wrote:
>
> > I had a look at this patch, seems like a useful thing to have.
>
> So the two initial questions for this patch are
>
> 1. Is this a feature we want?
> 2. I
pá 13. 9. 2019 v 9:35 odesílatel Pavel Stehule
napsal:
>
>
> čt 12. 9. 2019 v 0:01 odesílatel Alvaro Herrera from 2ndQuadrant <
> alvhe...@alvh.no-ip.org> napsal:
>
>> On 2019-Jul-31, Rafia Sabih wrote:
>>
>> > I had a look at this patch, seems lik
Hi
I testing very simple function
create or replace function f1(int) returns int as $$ declare i int = 0;
begin while i < $1 loop i = i + 1; end loop; return i; end $$ language
plpgsql immutable;
profile - when function is marked as immutable
8,65% postgres[.] ExecInterpExpr
Dne pá 13. 9. 2019 16:43 uživatel Tom Lane napsal:
> It struck me that the real reason that we keep getting gripes about
> the weird behavior of CHAR(n) is that these functions (and, hence,
> their corresponding operators) fail to obey the "trailing blanks
> aren't significant" rule:
>
>
Hi
út 17. 9. 2019 v 10:01 odesílatel Mitar napsal:
> Hi!
>
> I might have missed prior discussions about this, but I wonder if it
> would be possible to support binary payloads for NOTIFY/LISTEN? Again
> and again I find it very limiting with just text (have to base64
> encode data, or convert i
Hi
I started work on this patch. I changed syntax to
DROP DATABASE [ ( FORCE , ..) ] [IF EXISTS ...]
and now I try to fix all other points from Tom's list
út 17. 9. 2019 v 12:15 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > [ drop-database-force-20190708.patch ]
>
út 17. 9. 2019 v 16:10 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > út 17. 9. 2019 v 10:01 odesílatel Mitar napsal:
> >> I might have missed prior discussions about this, but I wonder if it
> >> would be possible to support binary payloads for NOTIFY/LIS
1
\pset linestyle ascii
\pset pager always
select * from generate_series(1,3);
Regards
Pavel
> Thanks,
>
> -- Ahsan
>
>
> On Mon, Sep 9, 2019 at 2:32 PM Pavel Stehule
> wrote:
>
>> Hi
>>
>> When I played with vertical cursor support I got badly disp
Hi
When I tested some hypothesis I wrote buggy code. It was surprise how fast
I lost all free memory
do $$
begin
for i in 1..300
loop
begin
-- do some error
if i then end if;
exception when others then
-- do nothing
end;
end loop;
end;
$$;
problem is somew
st 18. 9. 2019 v 4:53 odesílatel Ryan Lambert
napsal:
> Hi Pavel,
> I took a quick look through the patch, I'll try to build and test it
> tomorrow.
>
>
> --- a/src/include/nodes/parsenodes.h
> +++ b/src/include/nodes/parsenodes.h
> @@ -3145,6 +3145,7 @@ typedef struct DropdbStmt
> NodeTag type;
st 18. 9. 2019 v 4:57 odesílatel Pavel Stehule
napsal:
>
>
> st 18. 9. 2019 v 4:53 odesílatel Ryan Lambert
> napsal:
>
>> Hi Pavel,
>> I took a quick look through the patch, I'll try to build and test it
>> tomorrow.
>>
>>
>> --- a/s
st 18. 9. 2019 v 5:59 odesílatel vignesh C napsal:
> On Wed, Sep 18, 2019 at 8:30 AM Pavel Stehule
> wrote:
> >
> >
> Hi Pavel,
>
> One Comment:
> In the documentation we say drop database will fail after 60 seconds
>
> FORCE
>
>
st 18. 9. 2019 v 12:52 odesílatel Ahsan Hadi napsal:
>
>
> On Tue, Sep 17, 2019 at 8:16 PM Pavel Stehule
> wrote:
>
>>
>>
>> út 17. 9. 2019 v 17:06 odesílatel Ahsan Hadi
>> napsal:
>>
>>> Hi Pavel,
>>>
>>> I have been tryi
st 18. 9. 2019 v 19:11 odesílatel vignesh C napsal:
> On Wed, Sep 18, 2019 at 9:41 AM Pavel Stehule
> wrote:
> >
> >
> >
> > st 18. 9. 2019 v 5:59 odesílatel vignesh C napsal:
> >>
> >> On Wed, Sep 18, 2019 at 8:30 AM Pavel Stehule
> wrote:
Hi
I am sending updated version - the changes against last patch are two. I
use pg_terminate_backed for killing other terminates like Tom proposed. I
am not sure if it is 100% practical - on second hand the necessary right to
kill other sessions is almost available - and consistency with
pg_termi
čt 19. 9. 2019 v 13:52 odesílatel vignesh C napsal:
> On Thu, Sep 19, 2019 at 12:14 AM Pavel Stehule
> wrote:
> >
> > Hi
> >
> > I am sending updated version - the changes against last patch are two. I
> use pg_terminate_backed for killing other terminates like
st 18. 9. 2019 v 12:04 odesílatel Konstantin Knizhnik <
k.knizh...@postgrespro.ru> napsal:
>
>
> On 21.08.2019 11:54, Konstantin Knizhnik wrote:
>
>
>
> On 20.08.2019 20:01, Pavel Stehule wrote:
>
> Another solution is wait on ZHeap storage and replica can
pá 20. 9. 2019 v 7:58 odesílatel Dilip Kumar napsal:
> On Thu, Sep 19, 2019 at 12:14 AM Pavel Stehule
> wrote:
> >
> > Hi
> >
> > I am sending updated version - the changes against last patch are two. I
> use pg_terminate_backed for killing other terminates like
pá 20. 9. 2019 v 5:10 odesílatel Thomas Munro
napsal:
> On Thu, Sep 19, 2019 at 6:44 AM Pavel Stehule
> wrote:
> > I am sending updated version
>
> +appendPQExpBuffer(&sql, "DROP DATABASE %s%s%s;",
> + (force ? " (FORCE) " :
po 23. 9. 2019 v 9:57 odesílatel Konstantin Knizhnik <
k.knizh...@postgrespro.ru> napsal:
>
>
> On 20.09.2019 19:43, Pavel Stehule wrote:
>
>
> 1. I do not need them at all.
>> 2. Eliminate catalog bloating.
>> 3. Mostly needed for compatibility with Oracle (s
út 24. 9. 2019 v 14:52 odesílatel Amit Kapila
napsal:
> On Sat, Sep 21, 2019 at 10:09 PM Pavel Stehule
> wrote:
> >
> > Thank you for check. I am sending updated patch
> >
>
> Alvaro has up thread suggested some alternative syntax [1] for this
> patch, but I d
út 24. 9. 2019 v 17:51 odesílatel vignesh C napsal:
> On Tue, Sep 24, 2019 at 6:22 PM Amit Kapila
> wrote:
> >
> > On Sat, Sep 21, 2019 at 10:09 PM Pavel Stehule
> wrote:
> > >
> > > Thank you for check. I am sending updated patch
> > >
>
st 25. 9. 2019 v 6:38 odesílatel vignesh C napsal:
> On Sat, Sep 21, 2019 at 10:09 PM Pavel Stehule
> wrote:
> > fixed
> >
> > Thank you for check. I am sending updated patch
> >
> Thanks for fixing all the comments.
> Couple of suggestions:
> -DROP D
st 25. 9. 2019 v 4:14 odesílatel Amit Kapila
napsal:
> On Tue, Sep 24, 2019 at 6:22 PM Amit Kapila
> wrote:
> > On Sat, Sep 21, 2019 at 10:09 PM Pavel Stehule
> wrote:
> > >
> > > Thank you for check. I am sending updated patch
> > >
> >
>
čt 26. 9. 2019 v 17:35 odesílatel Alvaro Herrera
napsal:
> On 2019-Sep-26, Pavel Stehule wrote:
>
> > Alternative is DROP DATABASE [IF EXISTS] name [ CASCADE | RESTRICT ] [
> WITH
> > FORCE ]
> >
> > but in this case WIDTH keyword should not be optional (
čt 26. 9. 2019 v 18:34 odesílatel Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> napsal:
> On 2019-09-26 17:35, Alvaro Herrera wrote:
> > Well, you would have one of those:
> >
> > DROP DATABASE [IF EXISTS] name WITH (FORCE)
> > DROP DATABASE [IF EXISTS] name
> >
> > Naturally, the WITH is o
Hi
so 28. 9. 2019 v 3:53 odesílatel Nikita Glukhov
napsal:
> Attached 39th version of the patches rebased onto current master.
>
>
Regress tests fails on my comp - intel 64bit Linux, gcc 9.2.1
Comments:
* +<->/* Only XMLTABLE and JSON_TABLE are supported currently */
this comment has not sens
st 2. 10. 2019 v 5:20 odesílatel Amit Kapila
napsal:
> On Thu, Sep 26, 2019 at 7:18 PM Pavel Stehule
> wrote:
>
>>
>> út 24. 9. 2019 v 14:52 odesílatel Amit Kapila
>> napsal:
>>
>>>
>>> One other minor comment:
>>> +
>>>
Hi
so 10. 8. 2019 v 9:10 odesílatel Pavel Stehule
napsal:
> Hi
>
> just rebase
>
fresh rebase
Regards
Pavel
> Regards
>
> Pavel
>
schema-variables-20191004.patch.gz
Description: application/gzip
čt 3. 10. 2019 v 19:48 odesílatel vignesh C napsal:
> On Wed, Oct 2, 2019 at 10:21 PM Pavel Stehule
> wrote:
> >
> > Thank you for careful review. I hope so all issues are out.
> >
> >
> Thanks Pavel for fixing the comments.
> Few comments:
> The else part
ne 6. 10. 2019 v 10:19 odesílatel vignesh C napsal:
> On Fri, Oct 4, 2019 at 9:54 PM Pavel Stehule
> wrote:
> >
> >
> >
> > čt 3. 10. 2019 v 19:48 odesílatel vignesh C
> napsal:
> >>
> >> On Wed, Oct 2, 2019 at 10:21 PM Pavel Stehule
> wro
Hi
minor change - replace heap_tuple_fetch_attr by detoast_external_attr.
Regards
Pavel
pá 4. 10. 2019 v 6:12 odesílatel Pavel Stehule
napsal:
> Hi
>
> so 10. 8. 2019 v 9:10 odesílatel Pavel Stehule
> napsal:
>
>> Hi
>>
>> just rebase
>>
>
> fres
Hi
pá 11. 10. 2019 v 10:15 odesílatel Stefan Wolf napsal:
> I´ve written some PostgreSQL C-Extensions (for the first time...) and they
> work as expected.
>
> But now I want to call other functions from inside the C-Extensions (but
> not
> via SPI_execute),
> for example "regexp_match()" or from
pá 11. 10. 2019 v 15:50 odesílatel Konstantin Knizhnik <
k.knizh...@postgrespro.ru> napsal:
>
>
> On 11.10.2019 15:15, 曾文旌(义从) wrote:
>
> Dear Hackers,
>
> This propose a way to develop global temporary tables in PostgreSQL.
>
> I noticed that there is an "Allow temporary tables to exist as empty
Hi
po 30. 9. 2019 v 18:09 odesílatel Pavel Stehule
napsal:
> Hi
>
> so 28. 9. 2019 v 3:53 odesílatel Nikita Glukhov
> napsal:
>
>> Attached 39th version of the patches rebased onto current master.
>>
>>
This patch is still pretty big - it is about 6000 lin
so 19. 10. 2019 v 12:37 odesílatel Amit Kapila
napsal:
> On Fri, Oct 4, 2019 at 9:54 PM Pavel Stehule
> wrote:
> >
> >>
> >> Can we add few tests for this feature.
> >
> > there are not any other test for DROP DATABASE
> >
>
> I think ther
po 21. 10. 2019 v 7:11 odesílatel Amit Kapila
napsal:
> On Sun, Oct 20, 2019 at 2:06 AM Pavel Stehule
> wrote:
> >
> > so 19. 10. 2019 v 12:37 odesílatel Amit Kapila
> napsal:
> >>
> >> On Fri, Oct 4, 2019 at 9:54 PM Pavel Stehule
> wrote:
> >&
po 21. 10. 2019 v 8:38 odesílatel Amit Kapila
napsal:
> On Mon, Oct 21, 2019 at 11:08 AM Pavel Stehule
> wrote:
> >
> > po 21. 10. 2019 v 7:11 odesílatel Amit Kapila
> napsal:
> >>
> >> >(under low load (only pg_sleep was called).
> >>
Hi
> When you say 'without any problem', do you mean to say that the drop
> database is successful? In your tests were those sessions idle? If
> so, I think we should try with busy sessions. Also, if you write any
> script to do these tests, kindly share the same so that others can
> also repe
po 21. 10. 2019 v 10:25 odesílatel Amit Kapila
napsal:
> On Mon, Oct 21, 2019 at 12:24 PM Pavel Stehule
> wrote:
> >
> > po 21. 10. 2019 v 8:38 odesílatel Amit Kapila
> napsal:
> >>
> >> > If we don't wait in TerminateOtherDBBackends, then p
út 22. 10. 2019 v 5:09 odesílatel Amit Kapila
napsal:
> On Mon, Oct 21, 2019 at 2:15 PM Pavel Stehule
> wrote:
> >
> > po 21. 10. 2019 v 10:25 odesílatel Amit Kapila
> napsal:
> >>
> >>
> >> Sorry, but I am not able to understand the reaso
čt 24. 10. 2019 v 11:10 odesílatel Amit Kapila
napsal:
> On Wed, Oct 23, 2019 at 12:59 PM Amit Kapila
> wrote:
> >
> > On Tue, Oct 22, 2019 at 4:51 PM Pavel Stehule
> wrote:
> > >
> > > út 22. 10. 2019 v 5:09 odesílatel Amit Kapila
> napsal:
> >
pá 25. 10. 2019 v 17:01 odesílatel Robert Haas
napsal:
> On Fri, Oct 11, 2019 at 9:50 AM Konstantin Knizhnik
> wrote:
> > Just to clarify.
> > I have now proposed several different solutions for GTT:
> >
> > Shared vs. private buffers for GTT:
> > 1. Private buffers. This is least invasive patch
> >
> >> So except the limitation mentioned above (which I do not consider as
> critical) there is only one problem which was not addressed: maintaining
> statistics for GTT.
> >> If all of the following conditions are true:
> >>
> >> 1) GTT are used in joins
> >> 2) There are indexes defined for G
čt 28. 2. 2019 v 9:58 odesílatel Ramanarayana napsal:
> Hi,
>
> I have tested the three issues fixed in patch 001. Array Indexes
> issue is still there.Running the following query returns ERROR: more than
> one value returned by column XPath expression
>
> SELECT xmltable.*
> FROM (SELECT
s patch set was not finished, and is not in current
commitfest
please, check this set https://commitfest.postgresql.org/22/1872/
Regards
Pavel
> Regards,
> Ram.
>
> On Thu, 28 Feb 2019 at 15:01, Pavel Stehule
> wrote:
>
>>
>>
>> čt 28. 2. 2019 v 9:58 odesílatel R
401 - 500 of 2495 matches
Mail list logo
