Re: Check for tuplestorestate nullness before dereferencing

knowledge in not obvious for me) While Assert(tuplestorestate != NULL) gives much less information about what is happening here. And I think it is better to add this Assert there. People will continue using static analyzers on postgres code, finding this place again and again. Better to clo

Re: Check for tuplestorestate nullness before dereferencing

or it Do you have any idea how to test it? -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres Professional Matrix IM: @dhyan:nataraj.su signature.asc Description: This is a digitally signed message part.

Re: [PATCH] Check for TupleTableSlot nullness before dereferencing

the assumption that slot2 can > > theoretically be NULL, as there is such a check at line 968. Is it > > possible that no errors have occurred because this condition has always > > been satisfied and is, perhaps, redundant, or maybe I'm misunderstanding > > something?

Re: vacuum_truncate configuration parameter and isset_offset

or _all_ options that has custom behavior for unset option. Even those that a technically boolean. Why vacuum_truncate should do another way? Either do it the way it have been done before, or suggest total redisign for all oprions that has custom unset behaviour via unreachable defaults. This

Re: vacuum_truncate configuration parameter and isset_offset

ts that the > patch is "wrong", which I don't. This code is important part of my life for 8 years. There are not many commits, but I do code rebases all the time, I port features that have been added for all these years. I do care about it, it is big deal for me. -- Nikolay Sh

Re: vacuum_truncate configuration parameter and isset_offset

difference. If he would said isset_offset is good, I will follow. Until then I will follow my sense of harmony and code beauty as much as I can. -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres Professional Matrix IM: @dhyan:nataraj.su signature.asc Description: This is a digitall

Re: vacuum_truncate configuration parameter and isset_offset

l emotions, No, I am not yelling, and certainly I am not yelling as final argument. Can you please skip the form, that may be not perfect, and see the content. I hope that I managed to express the core idea quite clear. -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgre

Re: vacuum_truncate configuration parameter and isset_offset

cleanup option. I see there is a demand for this. But this will need carefull thinking and development. And starting from ugly Enum with boolean values would be much easy then from boolean with isset_offset. -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres Professional Matrix

Re: vacuum_truncate configuration parameter and isset_offset

to detect unset option, not some kind of flag. -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres Professional Matrix IM: @dhyan:nataraj.su signature.asc Description: This is a digitally signed message part.

Re: vacuum_truncate configuration parameter and isset_offset

o fix one option and leave, please do not leave us with isset_offset. This is not about democracy, this is about who will deal with that part of the code later. I guess it will be me and Alvaro, not you. Please let us have the code the way we like it, since we support it most of the time. -- Nik

Re: vacuum_truncate configuration parameter and isset_offset

option when needed. > But again, I don't see any strong reason why we must change all such > reloptions. Because code of the engine should be consistent. We can't have two different ways to do same thing. If we have isset flag, we should go for it everywhere, where isset logic exist

Re: vacuum_truncate configuration parameter and isset_offset

tions with custom unset behavior to use it, instead of unreachable default value. This will make it consistent then. -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres Professional Matrix IM: @dhyan:nataraj.su signature.asc Description: This is a digitally signed message part.

Re: vacuum_truncate configuration parameter and isset_offset

er of that knowledge. And second general idea: changing engine is bad, at least when you can manage without changing it. We can, your patch proves it. -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres Professional Matrix IM: @dhyan:nataraj.su signature.asc Description: This is a digitally signed message part.

Re: vacuum_truncate configuration parameter and isset_offset

ion engine. -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres Professional Matrix IM: @dhyan:nataraj.su signature.asc Description: This is a digitally signed message part.

Re: vacuum_truncate configuration parameter and isset_offset

do not use unreachable default value, but use null/unset flag. That is acceptable, if you really need this, but should be done to all options. But I do not think it worth efforts. -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres Professional Matrix IM: @dhyan:nataraj.su signature.asc

Re: vacuum_truncate configuration parameter and isset_offset

В письме от понедельник, 24 марта 2025 г. 15:27:35 MSK пользователь Nikolay Shaplov написал: > PS. I've just looked at code for vacuum_index_cleanup it has very same > logic, just replace "auto" with anything you like, and uses enum. > Grep for StdRdOptIndexCleanupValues

Re: vacuum_truncate configuration parameter and isset_offset

an optional integer > field to a single struct. That potentially changes the behaviour of all boolean options. They will never be what they were before. -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres Professional Matrix IM: @dhyan:nataraj.su signature.asc Description: Thi

Re: vacuum_truncate configuration parameter and isset_offset

relopt_enum_elt_def to declare a value > as "unsettable," right? That seems feasible, but IMHO it's comparable to > adding a field to reopt_parse_elt. If you look at view's check_option option, you will see, how unsettable enum default can be implemented using existing

Re: vacuum_truncate configuration parameter and isset_offset

feel like to have this, and there I feel like to have that". A option type that will be useful for everyone. If it is carefully considered, I will support it. -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres Professional Matrix IM: @dhyan:nataraj.su signature.asc Description: Th

Re: vacuum_truncate configuration parameter and isset_offset

uot;no new mechanism" is good. "new mechanism" is bad. :-) -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres Professional Matrix IM: @dhyan:nataraj.su signature.asc Description: This is a digitally signed message part.

Re: vacuum_truncate configuration parameter and isset_offset

values into three... It can't have three values for any practical reason. This should not be boolean anymore in this case. -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres Professional Matrix IM: @dhyan:nataraj.su signature.asc Description: This is a digitally signed message part.

Re: vacuum_truncate configuration parameter and isset_offset

and ALTER TABLE test RESET (vacuum_truncate); means "system_default" This will lead to a lot of confusion. So I strongly against this implying third value for boolean. This is nasty thing. Boolean should have two values. -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres Professional Matrix IM: @dhyan:nataraj.su signature.asc Description: This is a digitally signed message part.

Re: vacuum_truncate configuration parameter and isset_offset

then there would be confusion. Please do not do that. -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres Professional Matrix IM: @dhyan:nataraj.su signature.asc Description: This is a digitally signed message part.

vacuum_truncate configuration parameter and isset_offset

dex_cleanup it has very same logic, just replace "auto" with anything you like, and uses enum. Grep for StdRdOptIndexCleanupValues for more info StdRdOptIndexCleanupValues -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres Professional Matrix IM: @dhyan:nataraj.su signature.asc Description: This is a digitally signed message part.

Re: Minor rework of ALTER TABLE SET RelOptions code

refactoring > patch for 18. This is understandable. I will try to split this patch into parts for better readability in that time. -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres Professional Matrix IM: @dhyan:nataraj.su signature.asc Description: This is a digitally signed message part.

Minor rework of ALTER TABLE SET RelOptions code

alled with `RELKIND_TOASTVALUE` relation in the args, something is really wrong. We should throw asserts, errors and whistle as loud as we can. -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres Professional Matrix IM: @dhyan:nataraj.su >From 5618baa7a4efd075d402444aedc31437

Coverage with clang will now works

clang coverage manual. And you will get normal coverage. May be somebody will add this clang coverage to postgres build system, and we will have it via usual --enable-coverage. But that will not be me, I am no expert in build system and I already have not commited commitfest patches to take

Re: POC, WIP: OR-clause support for indexes

these checks into parts (compiler optimizer should take care about overhead) and give each part a sane explanation. -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres Professional Matrix IM: @dhyan:nataraj.su signature.asc Description: This is a digitally signed message part.

Re: POC, WIP: OR-clause support for indexes

В письме от понедельник, 24 июня 2024 г. 23:51:56 MSK пользователь Nikolay Shaplov написал: So, I continue reading the patch. I see there is `entries` variable in the code, that is the list of `RestrictInfo` objects and `entry` that is `OrClauseGroup` object. This naming is quite misguiding

Re: POC, WIP: OR-clause support for indexes

Hi! Let me join the review process. I am no expert in execution plans, so there would not be much help in doing even better optimization. But I can read the code, as a person who is not familiar with this area and help making it clear even to a person like me. So, I am reading v25-0001-Transf

Re: POC, WIP: OR-clause support for indexes

Hi! Let me join the review process. I am no expert in execution plans, so there would not be much help in doing even better optimization. But I can read the code, as a person who is not familiar with this area and help making it clear even to a person like me. So, I am reading v25-0001-Transf

Re: [PATCH] New [relation] option engine

nconsistency. > I'm not seeing any reasonable way to split this patch in smaller ones. Actually me neither. Not a good one anyway. But if somebody really need it to be split, it can be done that way. -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres Professional Matrix IM: @dhyan:nataraj.su signature.asc Description: This is a digitally signed message part.

Re: [PATCH] New [relation] option engine

will be total mess with two different options mechanisms working in the same time, but this might be much more easy to review. When we are done with the first step, we can change the rest. If this will help to finally include patch into postgres, I can do it. Will that help you to review? -

Build problem with square brackets in build path

no "[]" in the path to the source, everything is OK. It would be OK for me, if it still does not work. But I would appreciate at least proper error message there (or at configure step), this would save time, for figuring out, why it suddenly stopped working. -- Nikolay Shaplov aka Nata

Bug in jsonb_in function (14 & 15 version are affected)

ns to run conversion, and run the, in fuzzer. My colleagues (they will come here shortly) have narrowed down this query to SELECT E'\n"\\u0"'::jsonb; and says that is crashes even in utf8 locale. They also have a preliminary version of patch to fix it. They will tell

Re: [PATCH] New [relation] option engine

it. Guys sorry, I am totally unable to do just anything this month... Do not have spare resources to switch my attention to anything even this simple... Hope, next month will be better... And I will try to do some more reviewing of other patches... -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres Professional Matrix IM: @dhyan:nataraj.su signature.asc Description: This is a digitally signed message part.

Re: TAP output format in pg_regress

В письме от понедельник, 28 ноября 2022 г. 21:28:48 MSK пользователь Andres Freund написал: > On 2022-11-28 14:13:16 +0100, Daniel Gustafsson wrote: > > > On 27 Nov 2022, at 11:22, Nikolay Shaplov wrote: > > > В письме от суббота, 26 ноября 2022 г. 23:35:45 MS

Re: TAP output format in pg_regress

88 ms ok 13 types.float8 139 ms ok 14 types.bit165 ms ok 15 types.numeric 1065 ms but this does not seems very realistic in the current code bas

Re: TAP output format in pg_regress

um_parallel and fast_default) I guess the intention was to align them too... As for the rest: I see no other problems in the code, and consider it should be passed to commiter (or may be more experienced reviewer) > > On 24 Nov 2022, at 20:32, Andres Freund wrote: > > >

Re: TAP output format in pg_regress

better somehow narrow it to one ugly print... Print "ok %-5i"|"not ok %-5i" to buffer first, and then have one "%s%-*s %8.0f ms%s\n" print or something like that... I am not strongly insisting on that, but I feel strong urge to remove code duplication h

Re: TAP output format in pg_regress

of thinking is acceptable, please let me know, I will set myself as a reviewer and will dig further into the code. -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres Professional Matrix IM: @dhyan:nataraj.su signature.asc Description: This is a digitally signed message part.

Re: The "char" type versus non-ASCII characters

any cases that are not > problematic already. > > * Continue to allow non-ASCII values, but change charin/charout, > char_text, etc so that the external representation is encoding-safe > (perhaps make it an octal or decimal number). This will give us steady #1 for ascii_char, and deprecation and removal of "char" later on. -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres Professional Matrix IM: @dhyan:nataraj.su signature.asc Description: This is a digitally signed message part.

Re: Bug: Reading from single byte character column type may cause out of bounds memory reads.

ster` branch as well and > doesn't depend on the platform. > > Although the bug is easy to fix for this particular case (see the > patch) I'm not sure if this solution is general enough. E.g. is there > something that generally prevents pg_mblen() from doing out of bound >

Re: [PATCH] New [relation] option engine

table AM options is one of my next goals, as soon as this patch is commit. -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres Professional Matrix IM: @dhyan:nataraj.su signature.asc Description: This is a digitally signed message part.

Re: [PATCH] minor reloption regression tests improvement

В письме от четверг, 30 июня 2022 г. 06:47:48 MSK пользователь Nikolay Shaplov написал: > Hi! I am surely feel this patch is important. I have bigger patch > https://commitfest.postgresql.org/38/3536/ and this test makes sense as a > part of big work of options refactoring, > >

Re: [PATCH] minor reloption regression tests improvement

s refactoring, I am also was strongly advised to commit things chopped into smaller parts, when possible. This test can be commit separately so I am doing it. -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres Professional Matrix IM: @dhyan:nataraj.su signature.asc Description: This i

Re: Zstandard support for toast compression

became useful for other solutions. Encryption was just first example that came in my mind. Robert Haas has another example for compression method optimized for certain data type. So it is good if you can have method of your own. -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres P

Re: Zstandard support for toast compression

sion method chosen by user, and may be later extend it with another byte of compression method bits, if it is needed. -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres Professional Matrix IM: @dhyan:nataraj.su signature.asc Description: This is a digitally signed message part.

Re: [PATCH] minor reloption regression tests improvement

stake and did not notice it as it have not been properly tested. So I decided it would be goo to add test to it before adding and big patches. -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres Professional Matrix IM: @dhyan:nataraj.su

[PATCH] minor reloption regression tests improvement

do now. 2. This behaviour is reasonable. DB User can fix problem without updating pg_class, having rights to change his own table. 3. Better to get test alarm, if this behavior is accidentally changed. -- Nikolay Shaplov aka Nataraj Fuzzing Engineer at Postgres Professional Matrix IM: @dhyan:na

Re: [PATCH] Finally split StdRdOptions into HeapOptions and ToastOptions

eanup", RELOPT_TYPE_ENUM, in src/backend/access/common/reloptions.c This change should be done in 3499df0d But current implementation of reloptions is very error prone , and it is very easy to miss this part. -- Nikolay Shaplov dh...@nataraj.su (e-mail, jabber) @dhyan:nataraj.su (matrix)

Re: [PATCH] Finally split StdRdOptions into HeapOptions and ToastOptions

r. Testing and coauthoring will also be apriciated. My original big patch, I gave you link to, have been split into several parts. The last minor part, that should be commit in advance, and have not been commit yet is https://commitfest.postgresql.org/33/2370/ If you join as a reviewer this would be splendid! :-) -- Nikolay Shaplov dh...@nataraj.su (e-mail, jabber) @dhyan:nataraj.su (matrix)

Is deduplicate_items ever used in nbtree?

Hi! I am still working with reloptions patches, and noticed that in current master deduplicate_items option exists, but never actually used. You can set, it, you can dump it, it has proper representation in BTOptions, it is mentioned in documentation, but it is never actually used in the code. O

Re: [PATCH] Finally split StdRdOptions into HeapOptions and ToastOptions

В письме от понедельник, 20 июля 2020 г. 18:36:44 MSK пользователь Georgios Kokolatos написал: Hi! Sorry for really long delay, I was at my summer vacations, and then has urgent things to finish first. :-( Now I hope we can continue... > thank you for the patch. It applies cleanly, compiles a

Re: [PATCH] Finally split StdRdOptions into HeapOptions and ToastOptions

В письме от четверг, 2 июля 2020 г. 17:15:13 MSK пользователь Daniel Gustafsson написал: > > A new version of the patch. > > Autovacuum options were extended in b07642db > > > > So I added that options to the current patch. > > The heapam.c hunk in this version fails to apply to HEAD, can you p

Re: [PATCH] Finally split StdRdOptions into HeapOptions and ToastOptions

A new version of the patch. Autovacuum options were extended in b07642db So I added that options to the current patch.diff --git a/src/backend/access/common/reloptions.c b/src/backend/access/common/reloptions.c index e136116..55bd1ec 100644 --- a/src/backend/access/common/reloptions.c +++ b/src/ba

Re: [PATCH] Finally split StdRdOptions into HeapOptions and ToastOptions

В письме от суббота, 7 марта 2020 г. 10:03:40 MSK пользователь Michael Paquier написал: > On Wed, Mar 04, 2020 at 10:58:31PM +0300, Nikolay Shaplov wrote: > > But the truth is that my goal is to move all code that defines all option > > names, min/max values etc, move it inside a

Re: [PATCH] Finally split StdRdOptions into HeapOptions and ToastOptions

В письме от понедельник, 9 декабря 2019 г. 12:11:17 MSK пользователь Michael Paquier написал: > On Fri, Dec 06, 2019 at 06:18:48PM +0300, Nikolay Shaplov wrote: > > In the thread > > https://www.postgresql.org/message-id/2620882.s52SJui4ql@x200m > > I've suggested to

[PATCH] Finally split StdRdOptions into HeapOptions and ToastOptions

In the thread https://www.postgresql.org/message-id/2620882.s52SJui4ql@x200m I've suggested to split one big StdRdOption that is used for options storage into into Options structures individual for each relkind and each relam That patch have been split into smaller parts, most of them were alrea

Re: [PATCH] Do not use StdRdOptions in Access Methods

В письме от среда, 20 ноября 2019 г. 16:44:18 MSK пользователь Michael Paquier написал: > > It seems to me that if the plan is to have one option structure for > > each index AM, which has actually the advantage to reduce the bloat of > > each relcache entry currently relying on StdRdOptions, the

Re: [PATCH] Do not use StdRdOptions in Access Methods

В письме от четверг, 14 ноября 2019 г. 16:50:18 MSK пользователь Michael Paquier написал: > > I've changed the patch to use build_reloptions function and again propose > > it to the commitfest. > > Thanks for the new patch. I have not reviewed the patch in details, > but I have a small comment.

Re: [PATCH] use separate PartitionedRelOptions structure to store partitioned table options

В письме от среда, 13 ноября 2019 г. 16:30:29 MSK пользователь Michael Paquier написал: > On Tue, Nov 12, 2019 at 01:50:03PM +0900, Michael Paquier wrote: > > We have been through great length to have build_reloptions, so > > wouldn't it be better to also have this code path do so? Sure you > > n

Re: [PATCH] Do not use StdRdOptions in Access Methods

В письме от среда, 13 ноября 2019 г. 16:05:20 MSK пользователь Michael Paquier написал: Guys! Sorry for being away for so long. I did not have much opportunities to pay my attention to postgres recently. Thank you for introducing build_reloptions function. It is approximately the direction I w

Re: [PATCH] use separate PartitionedRelOptions structure to store partitioned table options

В письме от среда, 23 октября 2019 г. 11:59:45 MSK пользователь Amit Langote написал: > Sorry for the late reply. Same apologies from my side. Get decent time-slot for postgres dev only now. > I looked atthe v2 patch and noticed a typo: > > + * Binary representation of relation options fo

Re: [PATCH] Add some useful asserts into View Options macroses

В письме от пятница, 1 ноября 2019 г. 13:29:58 MSK пользователь Peter Eisentraut написал: > Committed. > > I simplified the parentheses by one level from your patch. Thank you! -- Software Developer: https://www.upwork.com/freelancers/~014a87e140ff02c0da Body-oriented Therapist: https://vk.co

Re: [PATCH] use separate PartitionedRelOptions structure to store partitioned table options

> > I think it is bad idea to suggest option adder to ad it to > > StdRdOption, we already have a big mess there. Better if he add it > > to an new empty structure. > > I tend to agree that this improves readability of the reloptions code > a bit. > > Some comments on the patch: > > How about nam

Re: [PATCH] Do not use StdRdOptions in Access Methods

В письме от четверг, 10 октября 2019 г. 17:17:30 MSK пользователь Amit Langote написал: > I read comments that Tomas left at: > https://www.postgresql.org/message-id/20190727173841.7ypzo4xuzizvijge%40deve > lopment > > I'd like to join Michael in reiterating one point from Tomas' review. > I thi

Re: [PATCH] use separate PartitionedRelOptions structure to store partitioned table options

В Thu, 10 Oct 2019 15:50:05 +0900 Amit Langote пишет: > > I think it is bad idea to suggest option adder to ad it to > > StdRdOption, we already have a big mess there. Better if he add it > > to an new empty structure. > > I tend to agree that this improves readability of the reloptions code > a

Re: [PATCH] Do not use StdRdOptions in Access Methods

В письме от среда, 9 октября 2019 г. 20:26:14 MSK пользователь Dent John написал: > I didn’t spot it was an existing pattern. Sorry, this might be my mistake I should explicitly mention it in the first place. > And I agree — making the code uniform will make it easier to evolve in > future. >

Re: [PATCH] use separate PartitionedRelOptions structure to store partitioned table options

В письме от вторник, 8 октября 2019 г. 16:00:49 MSK пользователь Amit Langote написал: > > > > The idea of this patch is following: If you read the code, partitioned > > > > tables do not have any options (you will not find > > > > RELOPT_KIND_PARTITIONED > > > > in boolRelOpts, intRelOpts, realR

Re: [PATCH] Add some useful asserts into View Options macroses

В письме от понедельник, 7 октября 2019 г. 12:59:27 MSK пользователь Robert Haas написал: > > This thread is a follow up to the thread > > https://www.postgresql.org/message-id/2620882.s52SJui4ql@x200m where I've > > been trying to remove StdRdOptions structure and replace it with unique > > stru

Re: [PATCH] Do not use StdRdOptions in Access Methods

В письме от понедельник, 7 октября 2019 г. 18:55:20 MSK пользователь Dent John написал: > I like the new approach. And I agree with the ambition — to split out the > representation from StdRdOptions. Thanks. > However, with that change, in the AM’s *options() function, it looks as if > you coul

Re: [PATCH] use separate PartitionedRelOptions structure to store partitioned table options

В письме от понедельник, 7 октября 2019 г. 14:57:14 MSK пользователь Michael Paquier написал: > On Sun, Oct 06, 2019 at 03:47:46PM +0300, Nikolay Shaplov wrote: > > This message is follow up to the "Get rid of the StdRdOptions" patch > > thread: https://www.postgres

Re: [PATCH] get rid of StdRdOptions, use individual binary reloptions representation for each relation kind instead

В письме от пятница, 27 сентября 2019 г. 17:24:49 MSK пользователь Michael Paquier написал: > The patch is in this state for two months now, so I have switched it > to "returned with feedback". So I've split this patch into even smaller parts, so it would be more easy to review. Do not use St

Re: [PATCH] Do not use StdRdOptions in Access Methods

Hi! I am starting a new thread as commitfest wants new thread for new patch. This new thread is a follow up to an https://www.postgresql.org/message-id/ 2620882.s52SJui4ql%40x200m thread, where I've been trying to get rid of StdRdOpions structure, and now I've splitted the patch into smaller part

[PATCH] use separate PartitionedRelOptions structure to store partitioned table options

Hi! This message is follow up to the "Get rid of the StdRdOptions" patch thread: https://www.postgresql.org/message-id/2620882.s52SJui4ql@x200m I've split patch into even smaller parts and commitfest want each patch in separate thread. So it is new thread. The idea of this patch is following: I

[PATCH] Add some useful asserts into View Options macroses

This thread is a follow up to the thread https://www.postgresql.org/message-id/2620882.s52SJui4ql@x200m where I've been trying to remove StdRdOptions structure and replace it with unique structure for each relation kind. I've decided to split that patch into smaller parts. This part adds some

Re: [PATCH] Do not use StdRdOptions in Access Methods

В Fri, 27 Sep 2019 17:24:49 +0900 Michael Paquier пишет: > > Looks like some good actionable feedback. I've moved this patch to > > September, and set it to "Waiting on Author". > > The patch is in this state for two months now, so I have switched it > to "returned with feedback". The latest pa

Re: [PATCH] src/test/modules/dummy_index -- way to test reloptions from inside of access method

В письме от вторник, 24 сентября 2019 г. 9:25:54 MSK пользователь Alvaro Herrera написал: > 0003 looks useful, thanks for completing it. I think it would be a good > idea to test invalid values for each type of reloption too (passing > floating point to integers, strings to floating point, and s

Re: [PATCH] src/test/modules/dummy_index -- way to test reloptions from inside of access method

В Fri, 20 Sep 2019 20:58:27 +0900 Michael Paquier пишет: Sorry I am really slow to answer... I hope it is not too late. > The GUCs are also basically not necessary, as you can just replace the > various WARNING calls (please don't call elog on anything which can be > reached by the user!) by lo

Re: [PATCH] src/test/modules/dummy_index -- way to test reloptions from inside of access method

В письме от четверг, 19 сентября 2019 г. 17:32:03 MSK пользователь Michael Paquier написал: > > src/test/modules/dummy_index_am directory check" I see a similar > > failure with "ERROR: unrecognized lock mode: 2139062143". I changed > > > that to a PANIC and got a core file containing this sta

Re: [PATCH] src/test/modules/dummy_index -- way to test reloptions from inside of access method

В Fri, 2 Aug 2019 11:12:35 +1200 Thomas Munro пишет: > While moving this to the September CF, I noticed this failure: > > test reloptions ... FAILED 32 ms Do you have any idea, how to reproduce this? I tried this patch on current master, and did not get result you are t

Re: [PATCH][PROPOSAL] Add enum releation option type

В письме от четверг, 5 сентября 2019 г. 11:42:27 MSK пользователь Alvaro Herrera from 2ndQuadrant написал: > After looking closer once again, I don't like this patch. > > I think the FOOBAR_ENUM_DEF defines serve no purpose, other than > source-code placement next to the enum value definitions.

Re: [PATCH] get rid of StdRdOptions, use individual binary reloptions representation for each relation kind instead

В письме от четверг, 4 июля 2019 г. 19:44:42 MSK пользователь Dent John написал: > Hi Nikolay, > > I have had a crack at re-basing the current patch against 12b2, but I didn’t > trivially succeed. > > It’s probably more my bodged fixing of the rejections than a fundamental > problem. But I now g

Why vacuum_index_cleanup is needed for TOAST relations?

I am importing recent changes into my reloption patch and came to a question, I did not find an answer... vacuum_index_cleanup option exists for both heap and toast relations. As I understand from documentation index cleanup is about is about reporting access method that some tuples in table th

Re: [PATCH] get rid of StdRdOptions, use individual binary reloptions representation for each relation kind instead

В письме от понедельник, 1 июля 2019 г. 23:52:13 MSK пользователь Thomas Munro написал: > > > This patch does not apply. > > > > Oh... Sorry... here goes new version > > > Hi Nikolay, > > Could we please have a new rebase? Sorry, a new reloptions have been introduced, and I need some time to

Re: [PATCH][PROPOSAL] Add enum releation option type

В письме от понедельник, 1 июля 2019 г. 14:06:28 MSK пользователь Alvaro Herrera написал: > It strikes me that the way to avoid sentence construction is to have > each enum reloption declare a string that it uses to list the values it > accepts. So for example we would have > > +#define GIST_OPT

Re: [PATCH][PROPOSAL] Add enum releation option type

В письме от понедельник, 1 июля 2019 г. 21:25:30 MSK пользователь Thomas Munro написал: > > It's not clear to me that all of Michael's and Álvaro's issues have been > > addressed, so I've marked this Waiting on Author. > To help reviewers for the Commitfest that is starting, could you > please re

Re: Ltree syntax improvement

В письме от воскресенье, 24 февраля 2019 г. 14:31:55 MSK пользователь Dmitry Belyavsky написал: Hi! Am back here again. I've been thinking about this patch a while... Come to some conclusions and wrote some examples... First I came to idea that the best way to simplify the code is change the

Re: [PATCH] src/test/modules/dummy_index -- way to test reloptions from inside of access method

real, boolean and string options. +do_test_reloption_string2 enables test output for another string option. We need +second string option, because a) string reloption implementation is a bit +tricky, and it is better to check that second value works as well; b) better to +check both cases: string opti

Re: Ltree syntax improvement

В письме от четверг, 7 марта 2019 г. 13:09:49 MSK пользователь Chris Travers написал: > We maintain an extension (https://github.com/adjust/wltree) > which has a fixed separator (::) and allows any utf-8 character in the tree. > > In our case we currently use our extended tree to store user-def

Re: [PATCH] get rid of StdRdOptions, use individual binary reloptions representation for each relation kind instead

В письме от среда, 20 марта 2019 г. 6:15:38 MSK пользователь Iwata, Aya написал: > You told us "big picture" about opclass around the beginning of this thread. > In my understanding, the purpose of this refactoring is to make reloptions > more flexible to add opclass. I understand this change may

Re: [PATCH] get rid of StdRdOptions, use individual binary reloptions representation for each relation kind instead

В письме от понедельник, 18 марта 2019 г. 17:00:24 MSK пользователь Kyotaro HORIGUCHI написал: > > So I change status to "Waiting for Author". > That seems to be a good oppotunity. I have some comments. > > rel.h: > -#define RelationGetToastTupleTarget(relation, defaulttarg) \ > -((relation)

Re: [PATCH] get rid of StdRdOptions, use individual binary reloptions representation for each relation kind instead

В письме от понедельник, 18 марта 2019 г. 3:03:04 MSK пользователь Iwata, Aya написал: > Hi Nikolay, Hi! Sorry for long delay. Postgres is not my primary work, so sometimes it takes a while to get to it. > This patch does not apply. Oh... Sorry... here goes new version > Please refer to http://

[PATCH][HOTFIX] vacuum_cost_delay type change from int to real have not been done everywhere

Hi! In caf626b2 type of vacuum_cost_delay have been switched from int to real, everywhere, but not in *RelOpts[] arrays. For some reason it continued to build and work. But I think it is better to move vacuum_cost_delay from int to real there too... Patch attached. PS. As you can see current

Re: [PATCH][PROPOSAL] Add enum releation option type

В письме от среда, 20 февраля 2019 г. 15:08:32 MSK пользователь Michael Paquier написал: > > 2.5 May be this src/test/modules dummy index is subject to another patch. > > So I will start working on it right now, but we will do this work not > > dependent to any other patches. And just add there

[PATCH] src/test/modules/dummy_index -- way to test reloptions from inside of access method

Hi! This patch introduce a dummy_index access method module, that does not do any indexing at all, but allow to test reloptions from inside of access method extension. This patch is part of my bigger work on reloptions refactoring. It came from https://www.postgresql.org/message-id/2019022006

Re: Ltree syntax improvement

В письме от вторник, 29 января 2019 г. 20:43:07 MSK пользователь Dmitry Belyavsky написал: > Dear all, > > Please find attached the patch extending the sets of symbols allowed in > ltree labels. The patch introduces 2 variants of escaping symbols, via > backslashing separate symbols and via quoti

Re: [PATCH][PROPOSAL] Add enum releation option type

В письме от среда, 20 февраля 2019 г. 15:08:32 MSK пользователь Michael Paquier написал: > On Sun, Jan 06, 2019 at 06:28:11PM +0300, Nikolay Shaplov wrote: > > Actually I am not satisfied with it too... That is why I started that > > bigger reloptions refactoring work. So for now I

Re: Ltree syntax improvement

В письме от вторник, 29 января 2019 г. 20:43:07 MSK пользователь Dmitry Belyavsky написал: > Please find attached the patch extending the sets of symbols allowed in > ltree labels. The patch introduces 2 variants of escaping symbols, via > backslashing separate symbols and via quoting the labels

  1   2   >