Re: [PATCH] Support Int64 GUCs

ding CF entry as "Rejected". Thanks to everyone involved! -- Best regards, Aleksander Alekseev

Re: [PATCH] Support Int64 GUCs

SYSTEM > ``` > > IIRC, the lexer only supports integers but not int64. Right. Supporting underscores for GUCs was discussed above but not implemented in the patch. As Alexander rightly pointed out this is not a priority and can be discussed separately. -- Best regards, Aleksander Alekseev

Re: [PATCH] Support Int64 GUCs

updates or deletes prior to vacuum. extra_desc | context | sighup vartype | int64 source | configuration file min_val | 0 max_val | 9223372036854775807 enumvals| boot_val| 50 reset_val | 1234605616436508552 sourcefile | /Users/eax/p

Re: [PATCH] Support Int64 GUCs

t uses these GUCs which results in casting int64s to ints. I would appreciate a bit more feedback on v2. If the community is fine with modifying these GUCs I will correct the patch in this respect. -- Best regards, Aleksander Alekseev

Re: [PATCH] Support Int64 GUCs

s is not implemented in the attached patch and arguably > > could be discussed separately when and if we merge it. > > I also think we're good with 12345678912345 so far. Fair enough. PFA the updated patch. [1]: https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADVISORY-LOCKS -- Best regards, Aleksander Alekseev v2-0001-Support-64-bit-integer-GUCs.patch Description: Binary data

Re: [PATCH] Support Int64 GUCs

?column? -- 123456 -- Best regards, Aleksander Alekseev

Re: Add 64-bit XIDs into PostgreSQL 15

s://commitfest.postgresql.org/50/5253/ -- Best regards, Aleksander Alekseev

[PATCH] Support Int64 GUCs

ErvAD9vZYA%40mail.gmail.com -- Best regards, Aleksander Alekseev v1-0001-Support-64-bit-integer-GUCs.patch Description: Binary data

Re: Add 64-bit XIDs into PostgreSQL 15

objects. We can always return to this later, preferably knowing that there is a particular committer who has time and energy for merging this. -- Best regards, Aleksander Alekseev

Re: [PATCH] Refactor SLRU to always use long file names

Hi Michael, > On Wed, Sep 11, 2024 at 04:07:06PM +0300, Aleksander Alekseev wrote: > > Commit 4ed8f0913bfd introduced long SLRU file names. The proposed > > patch removes SlruCtl->long_segment_names flag and makes SLRU always > > use long file names. This simplifies b

[PATCH] Refactor SLRU to always use long file names

mplained). I didn't include any tests for the new pg_upgrade code. To my knowledge we test it manually, with buildfarm members and during alpha- and beta-testing periods. Please let me know if you think there should be a corresponding TAP test. Thoughts? -- Best regards, Aleksander Alekseev

Re: Test improvements and minor code fixes for formatting.c.

Hi Tom, > Meh ... cfbot points out I did the float-to-int conversions wrong. > v2 attached. I'm having difficulties applying the patch. Could you please do `git format-patch` and resend it? -- Best regards, Aleksander Alekseev

Re: [PATCH] Add roman support for to_number function

generate_series(1, 3999) AS i ) SELECT bool_and(to_number(roman, 'RN') = i) FROM rows; bool_and -- t ``` ... in order to fix this while on it. The query takes ~12 ms on my laptop. -- Best regards, Aleksander Alekseev

Re: Commit Timestamp and LSN Inversion issue

ties understanding why this is a problem and why it was necessary to mention CDR in this context in the first place. OK, let's forget about CDR completely. Who is affected by the current behavior and why would it be beneficial changing it? -- Best regards, Aleksander Alekseev

Re: Commit Timestamp and LSN Inversion issue

larly to INSERT INTO ... ON CONFLICT ... semantics, or similar approaches from long-lived and well-explored distributed system, e.g. Riak. Alternatively / additionally we could support CRDTs in Postgres. -- Best regards, Aleksander Alekseev

Re: Add const qualifiers to XLogRegister*() functions

Hi, > On 04.10.23 16:37, Peter Eisentraut wrote: > > On 03.10.23 13:28, Aleksander Alekseev wrote: > >> While examining the code for similar places I noticed that the > >> following functions can also be const'ified: > > >> - XLogRegisterData (?) >

Re: [PATCH] Add get_bytes() and set_bytes() functions

Hi, > On 19.08.24 16:10, Aleksander Alekseev wrote: > > To clarify, supporting bytea<->integer (and/or bytea<->numeric) casts > > doesn't strike me as a terrible idea but it doesn't address the issue > > I'm proposing to solve. > > What is the

Re: [PATCH] Add get_bytes() and set_bytes() functions

integer (and/or bytea<->numeric) casts doesn't strike me as a terrible idea but it doesn't address the issue I'm proposing to solve. -- Best regards, Aleksander Alekseev

Re: [PATCH] Add get_bytes() and set_bytes() functions

comments on the patch. > > + * this routine treats "bytea" as an array of bytes. > > Maybe, the sentence should start with "This ... ". > > + while(size) > + { > > I wonder inserting a space after "while" is the standard s

Re: [PATCH] Add get_bytes() and set_bytes() functions

u never know who uses Postgres and for what purpose. I will add corresponding casts unless the idea will get a push-back from the community. IMO the existence of these casts will at least not make things worse. -- Best regards, Aleksander Alekseev

Re: [PATCH] Add get_bytes() and set_bytes() functions

hose who want little-endian. However I want to propose them separately when we are done with this patch. -- Best regards, Aleksander Alekseev

[PATCH] Add get_bytes() and set_bytes() functions

67788 ``` Thoughts? [1]: https://postgr.es/m/CAJ7c6TNMTGnqnG%3DyXXUQh9E88JDckmR45H2Q%2B%3DucaCLMOW1QQw%40mail.gmail.com [2]: https://stackoverflow.com/questions/32944267/postgresql-converting-bytea-to-bigint [3]: https://postgr.es/m/AANLkTikip9xs8iXc8e%2BMgz1T1701i8Xk6QtbVB3KJQzX%40mail.gmail.com --

Re: [PATCH] Add crc32(text) & crc32(bytea)

Hi, > WFM. Here is what I have staged for commit. Patch v5 LGTM. -- Best regards, Aleksander Alekseev

Re: libpq minor TOCTOU violation

n() call. But it seems formally incorrect, so it seems good to > fix it, at least to make the code a better example. Not entirely sure about the presence of a serious security issue but silencing a static analyzer sounds like a good idea, especially since the fix is simple. -- Best regards, Aleksander Alekseev

Re: format_datum debugging function

. Does it need a test? > Anything else? I think you forgot to attach the patch. Or is it just a proposal? -- Best regards, Aleksander Alekseev

Re: PostgreSQL's approach to assertion usage: seeking best practices

s usually a good idea unless the invariant is too expensive to check and/or complicated to read/understand. -- Best regards, Aleksander Alekseev

Re: Fsync (flush) all inserted WAL records

by users. Assuming the function has value, as you claim, I see no reason not to expose it similarly to pg_current_wal_*(). On top of that you will have to test-cover it anyway. The easiest way to do it will be to have an SQL-wrapper. -- Best regards, Aleksander Alekseev

Re: Fsync (flush) all inserted WAL records

/or applied on a replica. Your case(s) however is different and I don't fully understand it. In any case you will need to implement an SQL-wrapper in order to make the function available to DBAs, cover it with tests and provide documentation. -- Best regards, Aleksander Alekseev

Re: [PATCH] Add crc32(text) & crc32(bytea)

OK, here is the corrected patch v4. -- Best regards, Aleksander Alekseev v4-0001-Add-crc32-bytea-crc32c-bytea.patch Description: Binary data

Re: Fsync (flush) all inserted WAL records

GetInsertRecPtr() and others. I believe you will find all you need for the task. -- Best regards, Aleksander Alekseev

Re: Fsync (flush) all inserted WAL records

calls XLogBytePosToEndRecPtr() instead of XLogBytePosToRecPtr() inside it. > > Could you please advice which way to go? Does pg_current_wal_flush_lsn() [1] return what you need? [1]: https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-RECOVERY-CONTROL -- Best regards, Aleksander Alekseev

Re: [PATCH] Add crc32(text) & crc32(bytea)

ere seems to be a demand [1][2] and it will allow us to easily cast a `bytea` value to `integer` or `bigint`. This is probably another topic though. [1]: https://stackoverflow.com/questions/32944267/postgresql-converting-bytea-to-bigint [2]: https://postgr.es/m/AANLkTikip9xs8iXc8e%2BMgz1T1701i

Re: meson "experimental"?

hich was about $SUBJECT.) Thanks. Re-attaching 0001 and adding it to the nearest CF to make it visible on cfbot. -- Best regards, Aleksander Alekseev v1-0001-Meson-is-not-experimental-on-Windows.patch Description: Binary data

Re: Remove obsolete RECHECK keyword completely

, so this no > longer serves any need, it seems to me. > > This now removes it completely, and you'd get a normal parse error if > you used it. I reviewed and tested the code. LGTM. -- Best regards, Aleksander Alekseev

Re: [PATCH] Add crc32(text) & crc32(bytea)

c > > Perhaps these would fit into src/backend/utils/hash/pg_crc.c? Thanks, PFA patch v3. -- Best regards, Aleksander Alekseev v3-0001-Add-crc32-bytea-crc32c-bytea.patch Description: Binary data

Re: Is *fast* 32-bit support still important?

results you can't drop the support of 32-bit software (until it gets as difficult and pointless as with AIX that was dropped recently) and it will not tell you how slow the 32-bit version of PostgreSQL can be. If there are no actionable items why create a poll? -- Best regards, Aleksander Alekseev

Re: Is *fast* 32-bit support still important?

he performance of the upgrade procedure is probably not that important. The ability of processing a lot of data is probably also not extremely important, at least I wouldn't expect a lot of data and/or fast storage devices on 32-bit systems. -- Best regards, Aleksander Alekseev

Re: Detach shared memory in Postmaster child if not needed

h. How do you estimate its performance impact? Note the comments for postmaster_child_launch(). This function is exposed to the third-party code and guarantees to attach shared memory. I doubt that there is much third-party code in existence to break but you should change to comment. -- Best regards, Aleksander Alekseev

Re: [PATCH] Add crc32(text) & crc32(bytea)

ten in hexadecimal. > > I'm not sure we should call the check values "hashes." Wikipedia does > include them in the "List of hash functions" page [0], but it seems to > deliberately avoid calling them hashes in the CRC page [1]. I'd suggest > calling them "

Re: [PATCH] Add crc32(text) & crc32(bytea)

would be crc32c() or crc32(x, version='c') or perhaps crc32(x, polinomial=...). I propose keeping the scope small this time. -- Best regards, Aleksander Alekseev

Re: [PATCH] Add additional extended protocol commands to psql: \parse and \bindx

, for clarity, but my plan is to merge both 0001 > and 0002 together. I reviewed and tested v6. I believe it's ready to be merged. -- Best regards, Aleksander Alekseev

Re: Add new fielids only at last

Hi, > Currently, the new fields are only supported at the end, Cancannot move the > location of the field when editing the table, This does not seem to be an > elegant approach Pretty confident it was discussed many times before. Please use the search. -- Best regards, Aleksander Alekseev

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

code that uses SLRUs, and spotted three more > problematic code paths in predicate.c that needed an update like the > others for some pagenos. I've added these, and applied 0002. We > should be good now. Thank you! -- Best regards, Aleksander Alekseev

Re: Build with LTO / -flto on macOS

if I understood it correctly, is merely to do on MacOS the same we currently do on Linux. -- Best regards, Aleksander Alekseev

Re: Build with LTO / -flto on macOS

attention from the reviewers. Thus I changed the status of the CF entry to "Ready for Committer". -- Best regards, Aleksander Alekseev

Re: July Commitfest: Entries Needing Review

now require actions from the author. If you are an author and you know that you are going to update the patch, consider changing its status to "Waiting on Author" for the time being. This will allow the reviewers to focus on patches that actually didn't get any attention so far. -- Best regards, Aleksander Alekseev

[PATCH] Add crc32(text) & crc32(bytea)

og%40mail.gmail.com [2]: https://www.postgresql.org/message-id/flat/auto-000557707157%40umail.ru [3]: https://stackoverflow.com/questions/28179335/crc32-function-with-pl-pgsql [4]: https://gist.github.com/cuber/bcf0a3a96fc9a790d96d -- Best regards, Aleksander Alekseev v1-0001-Add-crc32-text-crc32-bytea.patch Description: Binary data

Re: Feature Request: Extending PostgreSQL's Identifier Length Limit

ml [2]: https://www.postgresql.org/docs/current/datatype-character.html -- Best regards, Aleksander Alekseev

Re: [PATCH] Refactor pqformat.{c,h} and protocol.h

Msg_Progress. I guess > PqMsg_ParallelProgress might be a tad more descriptive and less likely to > cause naming collisions with new frontend/backend messages, but I'm not > tremendously worried about either of those things. Thoughts? Personally I'm fine with either option. -- Best regards, Aleksander Alekseev

Re: [PATCH] Refactor pqformat.{c,h} and protocol.h

ude this patch: > - Patch 3 rearranges the order of the functions in pqformat.{c,h} a > bit to make the code easier to read. ... since arguably there is not much value in it. Please let me know if you think it's actually needed. -- Best regards, Aleksander Alekseev v3-0001-Add-PqMsg_

Re: [PATCH] Refactor pqformat.{c,h} and protocol.h

QcommMethods->putmessage() silently casts its first argument from `enum PqMsg` to `char` (shrug). -- Best regards, Aleksander Alekseev

Re: [PATCH] Refactor pqformat.{c,h} and protocol.h

Hi, > The proposed patchset fixes this. In v1 I mistakenly named the enum PgMsg while it should have been PqMsg. Here is the corrected patchset. -- Best regards, Aleksander Alekseev v2-0002-Introduce-PqMsg-enum.patch Description: Binary data v2-0001-Always-pass-PqMsg_-to-pq_beginmess

Re: temp table on commit delete rows performance issue

etc. If you have indexes for a temporary table it makes the situation ever worse. Sooner or later VACUUM will happen for your bloated catalog, and this is not fun under heavy load. Is there any particular reason why you don't want to simply change the target table directly? If you do it in a transaction you are safe. -- Best regards, Aleksander Alekseev

[PATCH] Refactor pqformat.{c,h} and protocol.h

e the code easier to read. [1]: https://www.postgresql.org/message-id/flat/1df84daa-7d0d-e8cc-4762-85523e45e5e7%40mailbox.org -- Best regards, Aleksander Alekseev v1-0001-Always-pass-PgMsg_-to-pg_beginmessage-_reuse.patch Description: Binary data v1-0002-Intoruce-PgMsg-enum.patch Descripti

Re: gcc 13 warnings

e start ignoring them and will skip something important one day. So I think we should do this. -- Best regards, Aleksander Alekseev

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

> 04X to know that short file names include 4 characters. I'm OK to > mention SlruFileName() rather than duplicate the knowledge here, but > SlruFileName() should also be updated to mention the same level of > details with some examples of file names. Fair enough. Here is th

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

nc.c. Alexander K., as the owner of the open > item, are you planning to look at that? Thanks, Michael. I prepared a corrected patchset. -- Best regards, Aleksander Alekseev v3-0001-Fix-the-comment-for-SlruCtlData.long_segment_name.patch Description: Binary data v3-0002-Use-int64-for-page-numbers-in-clog.c-async.c.patch Description: Binary data

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

Hi, > Here is the corrected patchset. TWIMC this is currently listed as an open item for PG17 [1]. Sorry if everyone interested is already aware. [1]: https://wiki.postgresql.org/wiki/PostgreSQL_17_Open_Items -- Best regards, Aleksander Alekseev

Re: MIN/MAX functions for a record

Hi, > Many thanks. Here is the corrected patch. Now it also includes MIN() > support and tests. Michael Paquier (cc:'ed) commented offlist that I forgot to change the documentation. Here is the corrected patch. -- Best regards, Aleksander Alekseev v3-0001-Support-min-record-and

Re: [PATCH] Add min/max aggregate functions to BYTEA

sure if this was the best choice. [1]: https://commitfest.postgresql.org/48/4905/ -- Best regards, Aleksander Alekseev

Re: gcc 13 warnings

olutely no idea :) -- Best regards, Aleksander Alekseev

Re: Adding skip scan (including MDAM style range skip scan) to nbtree

rate_series(0, 1_000_000); EXPLAIN ANALYZE SELECT COUNT(*) FROM test5 WHERE n > 950_000_000; ``` It runs fast and choses Index Only Scan. But then I discovered that without the patch Postgres also uses Index Only Scan for this query. I didn't know it could do this - what is the name of this technique? The query takes 17.6 ms with the patch, 21 ms without the patch. Not a huge win but still. That's all I have for now. -- Best regards, Aleksander Alekseev

Re: [PATCH] Add min/max aggregate functions to BYTEA

+(1 row) ``` If I understand correctly, all the v's are of the same size. If this is the case you should add more test cases. [1]: https://commitfest.postgresql.org/ -- Best regards, Aleksander Alekseev

Re: Cleanup: PGProc->links doesn't need to be the first field anymore

; > > ... > > I believe that was just an oversight. Trivial patch attached. I tested your patch. LGTM. PGPROC is exposed to third-party code, but since we don't change the structure this time, the extensions will not be affected. -- Best regards, Aleksander Alekseev

Re: Problem while installing PostgreSQL using make

t and `git format-path`. And in my humble experience this is something done often. -- Best regards, Aleksander Alekseev

Re: Problem while installing PostgreSQL using make

x27;t recommend this path for someone who wants to contribute. -- Best regards, Aleksander Alekseev

Re: Problem while installing PostgreSQL using make

However IMO your learning curve will be less steep with a Linux virtual machine. [1]: https://wiki.postgresql.org/wiki/Mailing_Lists [2]: https://github.com/afiskon/pgscripts/ -- Best regards, Aleksander Alekseev

Re: Problem while installing PostgreSQL using make

.4 You need something like flex 2.6.4 and bison >= 2.3. That's what I use. -- Best regards, Aleksander Alekseev

Re: Grammar guidelines in Postgres

ompiled by post > hackers and maintainers? I believe you wanted to reply to the mailing list, not to me directly. Please use the "Reply to All" button. Do the postfix operators you mention exist in the SQL standard? -- Best regards, Aleksander Alekseev

Re: Recommended books for admin

he title it's written from the DBAs perspective [1]: https://www.postgresql.org/docs/current/runtime-config-replication.html -- Best regards, Aleksander Alekseev

Re: Grammar guidelines in Postgres

uot; by Aho, Ullman et al [2] are good reads. I'm not entirely sure if it answers your question but I hope that it's helpful. [1]: https://www.amazon.com/Flex-Bison-John-R-Levine/dp/0596155972/ [2]: https://www.amazon.com/Compilers-Principles-Techniques-Tools-2nd/dp/0321486811/ -- Best regards, Aleksander Alekseev

Re: PostgreSQL does not compile on macOS SDK 15.0

chine unfortunately. -- Best regards, Aleksander Alekseev

Re: Useless parameter 'cur_skey' in IndexScanOK

y none of the compilers complained about this. Here is the patch. -- Best regards, Aleksander Alekseev From 7361a4b12262317e10c2203fed018be258beb16f Mon Sep 17 00:00:00 2001 From: Aleksander Alekseev Date: Wed, 3 Jul 2024 16:22:14 +0300 Subject: [PATCH v1] IndexScanOK: remove unused parameter

Re: What is a typical precision of gettimeofday()?

bles. > > Not sure this works even reasonably well for UUIDv7. UUIDv7 is not guaranteed to be unique. It just does it best to reduce the number of possible conflicts. So I don't think we should worry about it. -- Best regards, Aleksander Alekseev

Re: What is a typical precision of gettimeofday()?

that we use > microseconds, I’m not sure it’s ok to use 10 more bits for nanoseconds… A counter is mandatory since someone can for instance change the system's time while the process is generating UUIDs. You can't generally assume that local time of the system is monotonic. -- Best regards, Aleksander Alekseev

Re: Adding skip scan (including MDAM style range skip scan) to nbtree

r the patch - 127 ms. I realize this could be just something specific to my hardware and/or amount of data. Do you think this is something that was expected or something worth investigating further? I haven't looked at the code yet. [1]: https://github.com/afiskon/pgscripts/blob/master/single-install-meson.sh -- Best regards, Aleksander Alekseev

Re: CREATE OR REPLACE MATERIALIZED VIEW

mit that this information may be incorrect and/or outdated. -- Best regards, Aleksander Alekseev

Re: [PATCH] Handle SK_SEARCHNULL and SK_SEARCHNOTNULL in HeapKeyTest

here. The referred patch was rejected at first because it didn't modify nodeSeqScan.c to make use of the change within the core. I'm not saying this is necessarily applicable to this particular patch or that this is a general rule though. -- Best regards, Aleksander Alekseev

Re: [PATCH] Handle SK_SEARCHNULL and SK_SEARCHNOTNULL in HeapKeyTest

themself. As I recall, previously it was argued that changes like this should have some use within the core [1]. Can you think of any such use? [1]: https://commitfest.postgresql.org/42/4180/ -- Best regards, Aleksander Alekseev

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

le in the following grep match? > > src/backend/commands/async.c:1274: int headPage = > QUEUE_POS_PAGE(QUEUE_HEAD); Good catch. We better use int64s here. Here is the corrected patchset. -- Best regards, Aleksander Alekseev v2-0001-Fix-the-comment-for-SlruCtl

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

() makes 15-character (60-bit) file names. Where does the 48-bit > limit arise? How does the SlruFileName() comment about a 24-bit limit for > short names relate this comment's 16-bit limit? Yes, this comment is wrong. Here is a fix. [1]: https://www.postgresql.org/message-id/CAJ7c6TNM

Re: PostgreSQL does not compile on macOS SDK 15.0

ased. Thoughts? I added the patch to the nearest commitfest so that it wouldn't be lost [1]. [1]: https://commitfest.postgresql.org/48/5073/ -- Best regards, Aleksander Alekseev v1-0001-Dirty-fix.patch Description: Binary data

Re: PostgreSQL does not compile on macOS SDK 15.0

;Command Line Tools for Xcode" package (/Library/Developer/CommandLineTools/SDKs/). Or alternatively finding the official way of installing the beta version of this package. [1]: https://www.postgresql.org/docs/current/installation-platform-notes.html#INSTALLATION-NOTES-MACOS -- Best regards, Aleksander Alekseev

Re: call for applications: mentoring program for code contributors

Thanks Rovert and to everyone involved. -- Best regards, Aleksander Alekseev

Re: [PATCH] Improve error message when trying to lock virtual tuple.

, we can't lock it". ``` elog(ERROR, "cannot lock virtual tuple"); ``` For some reason I thought that ereport() is the preferred way of throwing errors, but I see elog() used many times in ExecLockRows() so this is probably fine. -- Best regards, Aleksander Alekseev

Re: RFC: adding pytest as a supported test framework

ll attract more contributors and thus would be a good step for the project in the long run. * including PyTest integration ** citation needed -- Best regards, Aleksander Alekseev

Re: meson "experimental"?

#x27;t give any value that would make it worth maintaining. -- Best regards, Aleksander Alekseev

Re: meson "experimental"?

mention of --backend option from [1] until it will, in order to avoid any confusion. [1]: https://www.postgresql.org/docs/devel/install-meson.html -- Best regards, Aleksander Alekseev

Re: Implementing CustomScan over an index

inimal example on GitHub and asking here. By a quick look I couldn't find an example of implementing a CustomScan in ./contrib/ or ./src/test/. If you can think of a usage example of CustomScans, consider contributing a test case. [1]: https://www.postgresql.org/docs/current/custom-scan.html [2]: https://github.com/timescale/timescaledb/ -- Best regards, Aleksander Alekseev

Re: meson "experimental"?

he buildfarm we seem to use Ninja >= 1.11.1. However since Meson can use both Ninja and VS as a backend I'm not certain which section would be most appropriate for naming the minimal required version of Ninja. -- Best regards, Aleksander Alekseev v1-0001-Meson-is-not-experimental-on-Windows.patch Description: Binary data v1-0002-Rename-section-17.7.5-to-Visual-Studio.patch Description: Binary data

Re: meson "experimental"?

gresql.org/docs/devel/install-meson.html [2]: https://www.postgresql.org/docs/devel/installation-platform-notes.html -- Best regards, Aleksander Alekseev

Re: Reading timestamp values from Datums gives garbage values

. See also commit 260a1f18 [1] and PostgreSQL documentation [2]. [1]: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=260a1f18 [2]: https://www.postgresql.org/docs/16/xfunc-c.html -- Best regards, Aleksander Alekseev

Re: Postgres and --config-file option

> I agree that it's not necessary or particularly useful for this hint > to be exhaustive. I could get behind your suggestion of > s/You must specify/Specify/, but I also think it's fine to do nothing. Fair enough, let's leave the help message as is then. I closed the corresponding CF entry. -- Best regards, Aleksander Alekseev

Re: Pre-Commitfest Party on StHighload conf

of the June - feel free to register anyway. > If you do not have a ticket to StHighload - we have some speaker entrance > tickets. > At the moment we have 4 potential patch authors ready to present. > > Please contact me with any questions regarding the event. Thanks! Great initiative, thanks! -- Best regards, Aleksander Alekseev

Re: Postgres and --config-file option

q.sgml and config.sgml bits > which are improvements of their own. Thanks, Michael. I propose my original v1 patch for correcting the --help output of 'postgres' too. I agree with the above comments that corresponding changes in v4 became somewhat unwieldy. -- Best regards, Ale

Re: Postgres and --config-file option

Hi, > Thanks for all your great input. Here is the updated patch. Here is the patch v4 with fixed typo ("geoq"). Per off-list feedback from Alvaro - thanks! -- Best regards, Aleksander Alekseev v4-0001-Clarify-error-message-about-specifying-config-fil.patch Description: Binary data

Re: Postgres and --config-file option

ting the long options with hyphens should generally be > preferred in documentation. Thanks for all your great input. Here is the updated patch. -- Best regards, Aleksander Alekseev From 1d55400adba93381d8a08249c95e4e16fb9a5945 Mon Sep 17 00:00:00 2001 From: "David G. Johnston"

Re: [PATCH] Replace magic constant 3 with NUM_MERGE_MATCH_KINDS

ast enum items. Thanks, fixed. -- Best regards, Aleksander Alekseev v2-0001-Use-macro-to-define-the-number-of-enum-values.patch Description: Binary data

Re: [PATCH] Fix bug when calling strncmp in check_authmethod_valid

ense, it can be resurrected (probably with a better > implementation). > > Any objections to fixing this in 17 by removing it? (cc:ing Michael from the > RMT) +1 Something that is not documented or used by anyone (apparently) and is broken should just be removed. -- Best regards, Aleksander Alekseev

Re: First draft of PG 17 release notes

integers rather than by 32-bit ones" where the authors are: Maxim Orlov, Aleksander Alekseev, Alexander Korotkov, Teodor Sigaev, Nikita Glukhov, Pavel Borisov, Yura Sokolov. -- Best regards, Aleksander Alekseev

  1   2   3   4   5   6   7   8   9   >