Hi
po 21. 2. 2022 v 6:19 odesílatel Noboru Saito napsal:
> I need a way to separate the results of \watch for each query execution.
>
> There is only a blank line between the results of \watch.
> However, there is also a blank line after the title, which complicates
> the rules.
>
> My suggestio
pá 25. 2. 2022 v 5:23 odesílatel Noboru Saito napsal:
> Hi,
>
> Pavel Stehule :
> > > I strongly agree. It was a lot of work to find a workable solution for
> pspg. Special chars that starting result and maybe other, that ending
> result can significantly increase robust
Hi
You redirect stats from pg_class and pg_statistics to a local hash table.
> This is pretty hairy :(
> I guess you'd also need to handle pg_statistic_ext and ext_data.
> pg_stats doesn't work, since the data isn't in pg_statistic - it'd need to
> look
> at pg_get_gtt_statistics.
>
Without this,
ne 27. 2. 2022 v 5:13 odesílatel Andres Freund napsal:
> Hi,
>
> On 2022-02-27 04:17:52 +0100, Pavel Stehule wrote:
> > > You redirect stats from pg_class and pg_statistics to a local hash
> table.
> > > This is pretty hairy :(
>
> As is I think the
po 28. 2. 2022 v 23:46 odesílatel Tom Lane napsal:
> Noboru Saito writes:
> > I have created a patch that allows you to turn it on and off in \pset.
> > The attached patch adds the following features.
> > Formfeed can be turned on with the command line option or \pset.
> > Formfeed (\f\n) is out
Hi
út 1. 3. 2022 v 14:39 odesílatel Aleksander Alekseev <
aleksan...@timescale.com> napsal:
> Hi hackers,
>
> I needed an aggregate function similar to array_agg() but which
> aggregates only unique values. As it turned out there is no convenient
> way of doing this. What I ended up doing instead
st 2. 3. 2022 v 19:02 odesílatel Adam Brusselback
napsal:
> >In my observation, very few users require an accurate query plan for
> temporary tables to
> perform manual analyze.
>
> Absolutely not true in my observations or personal experience. It's one of
> the main reasons I have needed to use
Hi
> I think you'd basically have to come up with a generic design for
> partitioning
> catalog tables into local / non-local storage, without needing explicit
> code
> for each catalog. That could also be used to store the default catalog
> contents separately from user defined ones (e.g. pg_pro
Hi
po 7. 3. 2022 v 3:31 odesílatel Julien Rouhaud napsal:
> On Mon, Mar 07, 2022 at 11:27:14AM +0900, Michael Paquier wrote:
> > On Sat, Mar 05, 2022 at 07:31:53PM +0900, Michael Paquier wrote:
> > > I got a short look at what was proposed in the patch a couple of
> > > months ago, and still fou
Hi
čt 17. 3. 2022 v 20:58 odesílatel Greg Stark napsal:
> It looks like this is -- like a lot of plpgsql patches -- having
> difficulty catching the attention of reviewers and committers.
> Aleksander asked for a test and Pavel put quite a bit of work into
> adding a good test case. I actually l
Hi
A bit more work seems to be needed for deparsing session variables:
>
> # create variable myvar text;
> CREATE VARIABLE
>
> # create view myview as select myvar;
> CREATE VIEW
>
> # \d+ myview
> View "public.myview"
> Column | Type | Collation | Nullable | Default |
po 30. 11. 2020 v 14:14 odesílatel Peter Eisentraut <
peter.eisentr...@enterprisedb.com> napsal:
> On 2020-11-29 18:36, Pavel Stehule wrote:
> >
> > I don't really get the point of this function. There is AFAICT no
> > function to produce this escaped f
po 30. 11. 2020 v 22:15 odesílatel Pavel Stehule
napsal:
>
>
> po 30. 11. 2020 v 14:14 odesílatel Peter Eisentraut <
> peter.eisentr...@enterprisedb.com> napsal:
>
>> On 2020-11-29 18:36, Pavel Stehule wrote:
>> >
>> > I don't really g
po 30. 11. 2020 v 22:56 odesílatel Pavel Stehule
napsal:
>
>
> po 30. 11. 2020 v 22:15 odesílatel Pavel Stehule
> napsal:
>
>>
>>
>> po 30. 11. 2020 v 14:14 odesílatel Peter Eisentraut <
>> peter.eisentr...@enterprisedb.com> napsal:
&g
út 1. 12. 2020 v 20:20 odesílatel Chapman Flack
napsal:
> >> po 30. 11. 2020 v 22:15 odesílatel Pavel Stehule <
> pavel.steh...@gmail.com>
> >> napsal:
> >>> I checked this and it is "prefix backslash-u hex" used by Java,
> >>&
st 2. 12. 2020 v 0:05 odesílatel Andrew Dunstan
napsal:
>
> On 11/30/20 8:14 AM, Peter Eisentraut wrote:
> > On 2020-11-29 18:36, Pavel Stehule wrote:
> >>
> >> I don't really get the point of this function. There is AFAICT no
> >> function to
st 2. 12. 2020 v 9:23 odesílatel Peter Eisentraut <
peter.eisentr...@enterprisedb.com> napsal:
> On 2020-11-30 22:15, Pavel Stehule wrote:
> > I would like some supporting documentation on this. So far we only
> > have
> > one stackoverflow question, and th
st 2. 12. 2020 v 12:55 odesílatel Peter Eisentraut <
peter.eisentr...@enterprisedb.com> napsal:
> While reading about deprecating and removing various things in other
> threads, I was wondering about how deprecated SELECT INTO is. There are
> various source code comments about this, but the SELEC
st 2. 12. 2020 v 11:37 odesílatel Pavel Stehule
napsal:
>
>
> st 2. 12. 2020 v 9:23 odesílatel Peter Eisentraut <
> peter.eisentr...@enterprisedb.com> napsal:
>
>> On 2020-11-30 22:15, Pavel Stehule wrote:
>> > I would like some supporting documentation on
st 2. 12. 2020 v 21:02 odesílatel Tom Lane napsal:
> Dmitry Dolgov <9erthali...@gmail.com> writes:
> >> On Wed, Dec 02, 2020 at 12:58:51PM -0500, Tom Lane wrote:
> >> So ... one of the things that's been worrying me about this patch
> >> from day one is whether it would create a noticeable perfor
út 8. 12. 2020 v 1:17 odesílatel Greg Nancarrow
napsal:
> On Fri, Dec 4, 2020 at 9:05 PM Konstantin Knizhnik
> wrote:
> >
> > As far as I understand Pavel concern was about the case when superuser
> > defines wrong login trigger which prevents login to the system
> > all user including himself.
Hi
čt 26. 11. 2020 v 12:46 odesílatel 曾文旌 napsal:
> This is the latest patch for feature GTT(v38).
> Everybody, if you have any questions, please let me know.
>
please, co you send a rebased patch. It is broken again
Regards
Pavel
>
> Wenjing
>
>
>
st 9. 12. 2020 v 7:34 odesílatel 曾文旌 napsal:
>
>
> 2020年12月8日 13:28,Pavel Stehule 写道:
>
> Hi
>
> čt 26. 11. 2020 v 12:46 odesílatel 曾文旌
> napsal:
>
>> This is the latest patch for feature GTT(v38).
>> Everybody, if you have any questions, please le
st 9. 12. 2020 v 13:17 odesílatel Greg Nancarrow
napsal:
> On Tue, Dec 8, 2020 at 3:26 PM Pavel Stehule
> wrote:
> >
> >
> > There are two maybe generic questions?
> >
> > 1. Maybe we can introduce more generic GUC for all event triggers like
> disable_
Hi
st 9. 12. 2020 v 13:17 odesílatel Greg Nancarrow
napsal:
> On Tue, Dec 8, 2020 at 3:26 PM Pavel Stehule
> wrote:
> >
> >
> > There are two maybe generic questions?
> >
> > 1. Maybe we can introduce more generic GUC for all event triggers like
>
st 9. 12. 2020 v 22:59 odesílatel Tom Lane napsal:
> Here's a couple of little finger exercises to move this along a bit.
>
> 0001 adds the ability to attach a subscript handler to an existing
> data type with ALTER TYPE. This is clearly going to be necessary
> if we want extension types to be a
st 9. 12. 2020 v 14:28 odesílatel Konstantin Knizhnik <
k.knizh...@postgrespro.ru> napsal:
>
>
> On 09.12.2020 15:34, Pavel Stehule wrote:
>
> Hi
>
> st 9. 12. 2020 v 13:17 odesílatel Greg Nancarrow
> napsal:
>
>> On Tue, Dec 8, 2020 at 3:26 PM Pavel Steh
čt 10. 12. 2020 v 14:03 odesílatel Konstantin Knizhnik <
k.knizh...@postgrespro.ru> napsal:
>
>
> On 10.12.2020 10:45, Pavel Stehule wrote:
>
>
>
> st 9. 12. 2020 v 14:28 odesílatel Konstantin Knizhnik <
> k.knizh...@postgrespro.ru> napsal:
>
>>
&
čt 10. 12. 2020 v 16:48 odesílatel Konstantin Knizhnik <
k.knizh...@postgrespro.ru> napsal:
>
>
> On 10.12.2020 18:12, Pavel Stehule wrote:
>
>
> My idea was a little bit different. Inside postinit initialize some global
> variables with info if there are event trigger
čt 10. 12. 2020 v 19:09 odesílatel Pavel Stehule
napsal:
>
>
> čt 10. 12. 2020 v 16:48 odesílatel Konstantin Knizhnik <
> k.knizh...@postgrespro.ru> napsal:
>
>>
>>
>> On 10.12.2020 18:12, Pavel Stehule wrote:
>>
>>
>> My idea was a little
pá 11. 12. 2020 v 16:07 odesílatel Konstantin Knizhnik <
k.knizh...@postgrespro.ru> napsal:
>
>
> On 09.12.2020 15:24, Pavel Stehule wrote:
>
>
>
> st 9. 12. 2020 v 13:17 odesílatel Greg Nancarrow
> napsal:
>
>> On Tue, Dec 8, 2020 at 3:26 PM Pavel Stehule
pá 11. 12. 2020 v 17:05 odesílatel Konstantin Knizhnik <
k.knizh...@postgrespro.ru> napsal:
>
>
> On 11.12.2020 18:40, Pavel Stehule wrote:
>
>
> is not correct. It makes it not possible to superuser to disable triggers
>> for all users.
>>
>
> pg_data
Hi
It is great. I expected much more work.
pá 11. 12. 2020 v 18:21 odesílatel Tom Lane napsal:
> We've had complaints in the past about how plpgsql can't handle
> assignments to fields in arrays of records [1], that is cases like
>
> arrayvar[n].field := something;
>
> and also complain
Hi
ne 13. 12. 2020 v 18:42 odesílatel Zhihong Yu napsal:
> Hi,
> I was experimenting with the following query.
>
> create table sint1(k int primary key, arr smallint[]);
> create index s1 on sint1(arr);
> insert into sint1 select s, array[s*s, s] FROM generate_series(1, 10) AS s;
> select * from
ne 13. 12. 2020 v 22:41 odesílatel Tom Lane napsal:
> I wrote:
> > So my idea here is to add a parsing-mode option to raw_parser(),
> > which would be an enum with values like "normal SQL statement",
> > "expression only", "type name", "plpgsql assignment statement".
>
> Here's a fleshed-out patc
Hi
I checked a performance and it looks so access to record's field is faster,
but an access to arrays field is significantly slower
do $$
declare
a int[];
aux int;
rep boolean default true;
begin
for i in 1..5000
loop
a[i]:= 5000 - i;
end loop;
raise notice '%', a[1:10];
wh
po 14. 12. 2020 v 14:31 odesílatel Heikki Linnakangas
napsal:
> On 11/12/2020 21:06, PegoraroF10 wrote:
> > I would like to have an anonymous block, like DO, but having resuts,
> like an
> > usual function does.
> >
> > I know any user can do ...
> >
> > create function pg_temp.run_time_bigger(nu
po 14. 12. 2020 v 17:25 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > I checked a performance and it looks so access to record's field is
> faster,
> > but an access to arrays field is significantly slower
>
> Hmm, I'd drawn the opposite conclusion i
út 15. 12. 2020 v 14:12 odesílatel Konstantin Knizhnik <
k.knizh...@postgrespro.ru> napsal:
>
>
> On 11.12.2020 19:27, Pavel Stehule wrote:
>
>
>
> pá 11. 12. 2020 v 17:05 odesílatel Konstantin Knizhnik <
> k.knizh...@postgrespro.ru> napsal:
>
>>
&
út 15. 12. 2020 v 15:06 odesílatel Konstantin Knizhnik <
k.knizh...@postgrespro.ru> napsal:
>
>
> On 15.12.2020 16:18, Pavel Stehule wrote:
>
>
>
> út 15. 12. 2020 v 14:12 odesílatel Konstantin Knizhnik <
> k.knizh...@postgrespro.ru> napsal:
>
>>
&
út 15. 12. 2020 v 15:06 odesílatel Konstantin Knizhnik <
k.knizh...@postgrespro.ru> napsal:
>
>
> On 15.12.2020 16:18, Pavel Stehule wrote:
>
>
>
> út 15. 12. 2020 v 14:12 odesílatel Konstantin Knizhnik <
> k.knizh...@postgrespro.ru> napsal:
>
>>
&
> Please notice that we still need GUC to disable on-login triggers: to make
>> it possible for superuser who did mistake and defined incorrect on-login
>> trigger to
>> login to the system.
>> Do we need GUC to disable all other event triggers? May be I am wrong,
>> but I do not see much need in s
út 15. 12. 2020 v 18:00 odesílatel Simon Riggs
napsal:
> On Fri, 17 Jul 2020 at 21:26, Nikita Glukhov
> wrote:
> >
> > Attached 50th version of the patches. Only the documentation was changed
> > since the previous version.
>
> I can imagine the effort required to get to v50, so I salute your ef
út 15. 12. 2020 v 19:56 odesílatel Oleg Bartunov
napsal:
> On Tue, Dec 15, 2020 at 8:37 PM Pavel Stehule
> wrote:
> >
> >
> >
> > út 15. 12. 2020 v 18:00 odesílatel Simon Riggs
> napsal:
> >>
> >> On Fri, 17 Jul 2020 at 21:26, Nikita Glukhov
út 15. 12. 2020 v 21:18 odesílatel Tom Lane napsal:
> I realized that the speedup patch I posted yesterday is flawed: it's
> too aggressive about applying the R/W param mechanism, instead of
> not aggressive enough.
>
> To review, the point of that logic is that if we have an assignment
> like
>
Attached please find new versoin of the patch based on
on_connect_event_trigger_WITH_SUGGESTED_UPDATES.patch
> So there is still only "disable_client_connection_trigger" GUC? because
> we need possibility to disable client connect triggers and there is no such
> need for other event types.
>
> As
st 16. 12. 2020 v 20:38 odesílatel Pavel Stehule
napsal:
> Attached please find new versoin of the patch based on
> on_connect_event_trigger_WITH_SUGGESTED_UPDATES.patch
>
>> So there is still only "disable_client_connection_trigger" GUC? because
>> we need possib
čt 17. 12. 2020 v 17:43 odesílatel Peter Eisentraut <
peter.eisentr...@enterprisedb.com> napsal:
> Along with the discussed change of the return type of EXTRACT from
> float8 to numeric [0], I was looking around what other date/time APIs
> might be using float arguments or return values. The only
čt 17. 12. 2020 v 14:04 odesílatel Konstantin Knizhnik <
k.knizh...@postgrespro.ru> napsal:
>
>
> On 17.12.2020 9:31, Pavel Stehule wrote:
>
>
>
> st 16. 12. 2020 v 20:38 odesílatel Pavel Stehule
> napsal:
>
>> Attached please
čt 17. 12. 2020 v 19:49 odesílatel Tom Lane napsal:
> Dmitry Dolgov <9erthali...@gmail.com> writes:
> > While rebasing the jsonb patch I found out that the current subscripting
> > assignment implementation in transformAssignmentIndirection always
> > coerce the value to be assigned to the type w
čt 17. 12. 2020 v 20:28 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > čt 17. 12. 2020 v 19:49 odesílatel Tom Lane napsal:
> >> So ... what's the problem with that? Seems like what you should put
> >> in and what you should get out should be the s
čt 17. 12. 2020 v 22:47 odesílatel Tom Lane napsal:
> Chapman Flack writes:
> > That's likely to be what a programmer intends when writing
> > (variable explicitly typed integer) := js['n'] and
> > (variable explicitly types varchar) := js['v']
>
> I think that what we want, if we're to support
Hi
only rebase
Regards
Pavel
schema-variables-20201219.patch.gz
Description: application/gzip
so 19. 12. 2020 v 21:35 odesílatel Tom Lane napsal:
> I wrote:
> > However, further experimentation found a case that fails:
> > regression=# select '3'::jsonb || '{}'::jsonb;
> > ERROR: invalid concatenation of jsonb objects
> > I wonder what is the point of this weird exception, and whether
>
čt 17. 12. 2020 v 19:30 odesílatel Pavel Stehule
napsal:
>
>
> čt 17. 12. 2020 v 14:04 odesílatel Konstantin Knizhnik <
> k.knizh...@postgrespro.ru> napsal:
>
>>
>>
>> On 17.12.2020 9:31, Pavel Stehule wrote:
>>
>>
>>
>&
Hi
some Orafce's user reported problems with pg_upgrade. I checked this issue
and it looks like pg_dump problem:
pg_restore: creating FUNCTION "public.nvarchar2("public"."nvarchar2",
integer, boolean)"
pg_restore: while PROCESSING TOC:
pg_restore: from TOC entry 612; 1255 33206 FUNCTION
nvarchar
po 21. 12. 2020 v 17:23 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > some Orafce's user reported problems with pg_upgrade. I checked this
> issue
> > and it looks like pg_dump problem:
> > ...
> > the supporting function should be dumped first b
Hi
po 21. 12. 2020 v 11:06 odesílatel Konstantin Knizhnik <
k.knizh...@postgrespro.ru> napsal:
>
>
> On 20.12.2020 10:04, Pavel Stehule wrote:
>
>
>
> čt 17. 12. 2020 v 19:30 odesílatel Pavel Stehule
> napsal:
>
>>
>>
>> čt 17. 12. 2020
út 22. 12. 2020 v 11:24 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Fri, Dec 18, 2020 at 08:59:25PM +0100, Dmitry Dolgov wrote:
> > > On Thu, Dec 17, 2020 at 03:29:35PM -0500, Tom Lane wrote:
> > > Dmitry Dolgov <9erthali...@gmail.com> writes:
> > > > On Thu, Dec 17, 2020 at 01
Hi
ne 20. 12. 2020 v 20:24 odesílatel Zhihong Yu napsal:
> Hi,
> I took a look at the rebased patch.
>
> + varisnotnull
> + boolean
> +
> +
> + True if the schema variable doesn't allow null value. The default
> value is false.
>
> I wonder whether the field can be na
ne 20. 12. 2020 v 21:43 odesílatel Zhihong Yu napsal:
> Hi,
> This is continuation of the previous review.
>
> +* We should to use schema variable buffer,
> when
> +* it is available.
>
> 'should use' (no to)
>
fixed
> + /* When buf
út 22. 12. 2020 v 17:57 odesílatel Tom Lane napsal:
> Dmitry Dolgov <9erthali...@gmail.com> writes:
> > On Tue, Dec 22, 2020 at 12:19:26PM +0100, Pavel Stehule wrote:
> >> I expect behave like
> >>
> >> update x set test[1] = 10; --> "[10]
út 22. 12. 2020 v 12:42 odesílatel Konstantin Knizhnik <
k.knizh...@postgrespro.ru> napsal:
>
>
> On 22.12.2020 12:25, Pavel Stehule wrote:
>
>
> regress tests fails
>
> sysviews ... FAILED 112 ms
> test event_trigger
út 22. 12. 2020 v 18:35 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Tue, Dec 22, 2020 at 11:57:13AM -0500, Tom Lane wrote:
> > Dmitry Dolgov <9erthali...@gmail.com> writes:
> > > On Tue, Dec 22, 2020 at 12:19:26PM +0100, Pavel Stehule w
Hi
I am playing with clipboard on Linux, and I found a way, how to redirect
psql output to clipboard via wl-copy or xclip and then to Libre Office. Now
it looks so best format is tsv
select * from pg_database \g (format=tsv) | wl-paste -t
application/x-libreoffice-tsvc
Implementation of tsv form
st 23. 12. 2020 v 15:21 odesílatel Bruce Momjian napsal:
> On Wed, Dec 23, 2020 at 07:18:24AM +0100, Pavel Stehule wrote:
> > Hi
> >
> > I am playing with clipboard on Linux, and I found a way, how to redirect
> psql
> > output to clipboard via wl-copy or xclip and
st 23. 12. 2020 v 16:24 odesílatel Tom Lane napsal:
> Bruce Momjian writes:
> > On Wed, Dec 23, 2020 at 07:18:24AM +0100, Pavel Stehule wrote:
> >> Implementation of tsv format should not be hard.
> >> What do you think about this?
>
> > How would you h
st 23. 12. 2020 v 16:54 odesílatel Bruce Momjian napsal:
> On Wed, Dec 23, 2020 at 04:39:48PM +0100, Pavel Stehule wrote:
> >
> >
> > st 23. 12. 2020 v 16:24 odesílatel Tom Lane napsal:
> >
> > Bruce Momjian writes:
> > > On Wed, Dec 23, 202
st 23. 12. 2020 v 17:38 odesílatel Andreas Karlsson
napsal:
> On 12/23/20 7:18 AM, Pavel Stehule wrote:> I am playing with clipboard
> on Linux, and I found a way, how to redirect
> > psql output to clipboard via wl-copy or xclip and then to Libre Office.
> > Now it looks
so 19. 12. 2020 v 7:57 odesílatel Pavel Stehule
napsal:
> Hi
>
> only rebase
>
rebase and comments fixes
Regards
Pavel
> Regards
>
> Pavel
>
schema-variables-20201222.patch.gz
Description: application/gzip
so 26. 12. 2020 v 7:18 odesílatel Erik Rijkers napsal:
> On 2020-12-26 05:52, Pavel Stehule wrote:
> > so 19. 12. 2020 v 7:57 odesílatel Pavel Stehule
> >
> > napsal:
> > [schema-variables-20201222.patch.gz (~]
> >
> >> Hi
> >>
> >> o
Hi
Thank you.
> I have applied all your fixes in on_connect_event_trigger-12.patch.
>
> Concerning enable_client_connection_trigger GUC, I think that it is really
> useful: it is the fastest and simplest way to disable login triggers in case
> of some problems with them (not only for superuser it
so 26. 12. 2020 v 8:00 odesílatel Pavel Stehule
napsal:
> Hi
>
>
> Thank you.
>> I have applied all your fixes in on_connect_event_trigger-12.patch.
>>
>> Concerning enable_client_connection_trigger GUC, I think that it is
>> really useful: it is the faste
Hi
I repeated tests. I wrote a set of simple functions. It is a synthetical
test, but I think it can identify potential problems well.
I calculated the average of 3 cycles and I checked the performance of each
function. I didn't find any problem. The total execution time is well too.
Patched code
Hi
maybe interesting project for decreasing overhead of JIT
https://developers.redhat.com/blog/2020/01/20/mir-a-lightweight-jit-compiler-project/
Regards
Pavel
so 26. 12. 2020 v 19:00 odesílatel Pavel Stehule
napsal:
> Hi
>
> I repeated tests. I wrote a set of simple functions. It is a synthetical
> test, but I think it can identify potential problems well.
>
> I calculated the average of 3 cycles and I checked the performance of
po 28. 12. 2020 v 0:55 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > Now, the behavior of SELECT INTO is behind the assign statement and this
> > fact should be documented. Usually we don't need to use array's fields
> > here, but somebody can try it.
st 30. 12. 2020 v 14:46 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Wed, Dec 30, 2020 at 02:45:12PM +0100, Dmitry Dolgov wrote:
> > > On Sat, Dec 26, 2020 at 01:24:04PM -0500, Tom Lane wrote:
> > >
> > > In a case like jsonpath['...'], the initially UNKNOWN-type literal
> could
čt 31. 12. 2020 v 15:27 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Wed, Dec 30, 2020 at 09:01:37PM +0100, Dmitry Dolgov wrote:
> > > make check fails
> >
> > Yeah, apparently I forgot to enable asserts back after the last
> > benchmarking discussion, and missed some of those.
Hi
only rebase
Regards
Pavel
diff --git a/src/backend/commands/prepare.c b/src/backend/commands/prepare.c
index 89087a7be3..b1d2f1af37 100644
--- a/src/backend/commands/prepare.c
+++ b/src/backend/commands/prepare.c
@@ -230,7 +230,7 @@ ExecuteQuery(ParseState *pstate,
entry->plansou
Hi
fresh rebase
Regards
Pavel
schema-variables-20210101.patch.gz
Description: application/gzip
Hi
rebase
Regards
Pavel
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index 11246aa653..89a07678ee 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -4606,6 +4606,99 @@ CREATE EVENT TRIGGER snitch ON ddl_command_start EXECUTE FUNCTION snitch();
Hi
ne 3. 1. 2021 v 13:13 odesílatel Joel Jacobson napsal:
> Hi hackers,
>
> I just learned about a feature called "LET clause".
>
> It's not part of the SQL standard, but it's supported by Oracle
> [1], Couchbase [2] and AsterixDB [3].
>
This is not SQL language - it uses EQL language
It looks
Hi
I continue in review.
I found inconsistency in work with slicings (this is not directly related
to this patch, but can be interesting, because with new functionality the
array slicings can be edited more often).
a = array[1,2,3,4,5];
a[1:5] = 10; -- correctly fails, although for some people c
ne 3. 1. 2021 v 19:07 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > I found inconsistency in work with slicings (this is not directly related
> > to this patch, but can be interesting, because with new functionality the
> > array slicings can be edited more of
Hi
probably some is wrong still
create table foo(a jsonb);
update foo set a['a'] = '10';
update foo set a['b']['c'][1] = '10';
update foo set a['b']['c'][10] = '10'
WARNING: problem in alloc set ExprContext: req size > alloc size for chunk
0x256dd88 in block 0x256d160
WARNING: problem in alloc
a comment for the choice of constant 3.
>
> + /* by default we allocate 30 bytes */
> + *realsize = 0;
>
> The value 30 may not be accurate - from the caller:
>
> + if (PG_ARGISNULL(2))
> + minsize = VARLENA_MINSIZE;
> + else
> +
po 4. 1. 2021 v 14:58 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Sun, Jan 03, 2021 at 08:41:17PM +0100, Pavel Stehule wrote:
> >
> > probably some is wrong still
> >
> > create table foo(a jsonb);
> > update foo set a['a
Hi
fix broken regress test
Regards
Pavel
diff --git a/src/pl/plpgsql/src/pl_comp.c b/src/pl/plpgsql/src/pl_comp.c
index 5336793a93..585959e12f 100644
--- a/src/pl/plpgsql/src/pl_comp.c
+++ b/src/pl/plpgsql/src/pl_comp.c
@@ -377,6 +377,10 @@ do_compile(FunctionCallInfo fcinfo,
*/
plpgsql_ns_
út 5. 1. 2021 v 18:51 odesílatel Bruce Momjian napsal:
> On Mon, Jan 4, 2021 at 09:46:32AM -0700, David G. Johnston wrote:
> > On Mon, Jan 4, 2021 at 8:26 AM Joel Jacobson wrote:
> >
> > In the documentation at https://www.postgresql.org/docs/current/
> > functions-admin.html
> > th
and then use the constant result of that
> decision,
> instead of relying on caching of functions.
>
> Here is the code for the scenario described:
>
> https://github.com/truthly/uniphant/commit/da12465818a62e69355dad126648c15a11871c12#diff-fe0f50327c9772bdf4baa8944856716da16706f09
út 5. 1. 2021 v 21:34 odesílatel Pavel Stehule
napsal:
>
>
> út 5. 1. 2021 v 20:23 odesílatel Joel Jacobson napsal:
>
>> út 5. 1. 2021 v 18:51 odesílatel Bruce Momjian napsal:
>> > I think I tried to make this feature more visible a few years ago and
>> >
út 5. 1. 2021 v 22:15 odesílatel Joel Jacobson napsal:
> On Tue, Jan 5, 2021, at 21:34, Pavel Stehule wrote:
> > yes, it is supported. More the schema variables supports RESET to
> default on transaction end,
> > and supports access rights for usage in security definer f
>
>
>
>> SET
>> g = year % 19,
>> c = year / 100,
>> h = (c - c/4 - (8*c + 13)/25 + 19*g + 15) % 30,
>> i = h - (h/28)*(1 - (h/28)*(29/(h + 1))*((21 - g)/11)),
>> j = year + year/4 + i + 2 - c + c/4) % 7,
>> p = i - j,
>> easter_month = 3 + (p + 26)/30,
>> easter_day = 1 + (p + 27 +
Hi
út 5. 1. 2021 v 20:32 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Mon, Jan 04, 2021 at 06:56:17PM +0100, Pavel Stehule wrote:
> > po 4. 1. 2021 v 14:58 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
> > napsal:
> > postgres=#
čt 7. 1. 2021 v 4:20 odesílatel Merlin Moncure napsal:
> On Tue, Jan 5, 2021 at 3:40 PM Tom Lane wrote:
> >
> > easter...@verfriemelt.org writes:
> > > i found, that the behaviour of variable assignment in combination with
> union is not working anymore:
> > > DO $$
> > > DECLARE t bool;
> >
čt 7. 1. 2021 v 9:15 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Wed, Jan 06, 2021 at 09:22:53PM +0100, Pavel Stehule wrote:
> >
> > this case should to raise exception - the value should be changed or
> error
> > should be raised
> >
čt 7. 1. 2021 v 17:29 odesílatel Merlin Moncure napsal:
> On Wed, Jan 6, 2021 at 11:07 PM Pavel Stehule
> wrote:
>
> > čt 7. 1. 2021 v 4:20 odesílatel Merlin Moncure
> napsal:
> >>
> >> On Tue, Jan 5, 2021 at 3:40 PM Tom Lane wrote:
> >> >
>
Hi
just rebase
Regards
Pavel
schema-variables-20200108.patch.gz
Description: application/gzip
pá 1. 1. 2021 v 9:15 odesílatel Pavel Stehule
napsal:
> Hi
>
> only rebase
>
rebase
regards
Pavel
> Regards
>
> Pavel
>
diff --git a/src/backend/commands/prepare.c b/src/backend/commands/prepare.c
index 653ef8e41a..6f8643cc4a 100644
--- a/src/backend/commands/pre
1 - 100 of 2474 matches
Mail list logo