В письме от понедельник, 31 декабря 2018 г. 19:04:08 MSK пользователь Nikolay
Shaplov написал:
> I'd like to propose a small patch for make_ctags script. It checks if ctags
> utility is intalled or not. If not it reports an error and advises to
> install ctags.
Oups. I've misp
I've been trying to use vim for postgres development some yeas ago, but I did
not manage to do it for log time, as I quit the job etc.
Now I am trying again, but I've lost my .vimrc and notes and had to start from
the very beginning. I vaguely remember what tools I've been using, but I have
to
В письме от вторник, 1 января 2019 г. 11:24:11 MSK пользователь Michael
Paquier написал:
> Not sure if that's something worse bothering about, but you could do
> the same in src/tools/make_etags.
Good idea. Done.
(I did not do it in the first place because I do not use etags and can't
properly
В письме от пятница, 30 ноября 2018 г. 23:57:21 MSK пользователь Dmitry Dolgov
написал:
> Looks like there are some problems with this patch on windows:
> src/backend/access/common/reloptions.c(1469): error C2059: syntax error :
> '}'
>
> https://ci.appveyor.com/project/postgresql-cfbot/postgr
В письме от пятница, 2 ноября 2018 г. 23:52:13 MSK пользователь Nikolay
Shaplov написал:
> > In this case the only solution I can see is
> >
> > DETAIL: Valid values are: "value1", "value2", "value3".
> >
> > Where list '&quo
В письме от среда, 2 января 2019 г. 0:05:10 MSK пользователь Alvaro Herrera
написал:
> One thing I would like to revise here is to avoid unnecessary API change
> -- for example the RelationHasCascadedCheckOption macro does not really
> need to be renamed because it only applies to views, so there'
В письме от четверг, 3 января 2019 г. 10:03:53 MSK пользователь Michael
Paquier написал:
> On Wed, Jan 02, 2019 at 11:35:46AM -0500, Tom Lane wrote:
> > In fact, that's demonstrably not so: on my RHEL6 and Fedora boxes,
> > /usr/bin/etags isn't owned by any package, because it's a symlink
> > mana
В письме от среда, 2 января 2019 г. 8:59:13 MSK пользователь James Coleman
написал:
> > So I decided to write it down to a wiki article, while I am restoring the
> > configuration so I do not have to remember them for the third time, if I
> > loose .vimrc again. :-)
>
> I like expanding the smal
В письме от четверг, 3 января 2019 г. 16:10:20 MSK пользователь Alvaro Herrera
написал:
> On 2019-Jan-02, Nikolay Shaplov wrote:
> > This is internal API, right? If we change it everywhere, then it is
> > changed and nothing will be broken?
>
> No, it's exported for
В письме от четверг, 3 января 2019 г. 12:52:36 MSK пользователь Peter
Eisentraut написал:
> >> +1, let's keep it simple. I would just use "ctags/etags not found"
> >> as error message.
> >
> > Actually I was trying to say "Please install 'ctags' [utility] to run
> > make_ctags". But if all of y
В письме от четверг, 3 января 2019 г. 18:12:05 MSK пользователь Alvaro Herrera
написал:
> Attached version 7, with some renaming and rewording of comments.
> (I also pgindented. Some things are not pretty because of lack of
> typedefs.list patching ... a minor issue at worst.)
Thanks! Imported it
В письме от четверг, 3 января 2019 г. 17:15:08 MSK пользователь Alvaro Herrera
написал:
> I would have liked to get a StaticAssert in the definition, but I don't
> think it's possible. A standard Assert() should be possible, though.
Asserts are cool thing. I found some unexpected stuff.
paral
В письме от четверг, 3 января 2019 г. 17:15:08 MSK пользователь Alvaro Herrera
написал:
> > Can we think about backward compatibility aliases?
.
> > And keep them for as log as needed to avoid #if VERSION in thirdparty
> > code?
> Well, if you do this, at some point you need to tell the exten
В письме от воскресенье, 6 января 2019 г. 17:50:36 MSK пользователь Andrew
Dunstan написал:
> > The correct way to code this is to depend on the exit code,
> > not the text output:
> >
> > if command -v etags >/dev/null
> > then
> > : ok
> > else
> > echo etags not found
> > exit 1
> > fi
В письме от понедельник, 7 января 2019 г. 13:56:48 MSK пользователь Alvaro
Herrera написал:
> > Asserts are cool thing. I found some unexpected stuff.
> >
> > parallel_workers option is claimed to be heap-only option.
> >
> > But in src/backend/optimizer/util/plancat.c in get_relation_info
> >
В письме от понедельник, 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
В письме от суббота, 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
В письме от понедельник, 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
В письме от понедельник, 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
В письме от понедельник, 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
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
В письме от четверг, 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
В письме от понедельник, 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
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
В письме от 28 ноября 2017 11:23:38 пользователь Michael Paquier написал:
> On Tue, Nov 28, 2017 at 11:22 AM, Michael Paquier
>
> wrote:
> > On Tue, Nov 14, 2017 at 4:44 PM, Michael Paquier
> >
> > wrote:
> >> On Mon, Oct 30, 2017 at 9:49 AM, Nikolay
В письме от 10 сентября 2018 18:02:10 пользователь Aleksandr Parfenov написал:
> I did a quick look at yout patch and have some questions/points to
> discuss. I like the idea of the patch and think that enum reloptions
> can be useful. Especially for some frequently checked values, as it was
> men
Hi!
I've rebased the patch against recent master.
I've imported changes from 857f9c36 commit.
BTW this commit shows why do this patch is important: 857f9c36 adds new option
for b-tree indexes. But thanks to the StdRdOptions this option will exist for
no practical use in all heaps that has just a
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
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.
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
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.
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
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.
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.
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.
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.
В письме от понедельник, 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
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.
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
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
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
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.
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
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
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.
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
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
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
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.
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?
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
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
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.
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
101 - 154 of 154 matches
Mail list logo
