Re: CREATE SCHEMA ... CREATE DOMAIN support

Kirill Reshke writes: > 3) Why do we delete this in `create_schema.sgml`? Is this untrue? It > is about order of definition, not creation, isn't it? >> - The SQL standard specifies that the subcommands in CREATE >> - SCHEMA can appear in any order. In context with the following sentence, wha

Re: CREATE SCHEMA ... CREATE DOMAIN support

On Sun, 1 Dec 2024 at 04:33, Tom Lane wrote: > I looked at several iterations of the SQL standard > and cannot find any support for the idea that CREATE SCHEMA needs to > be any smarter than that. I'd also argue that doing anything else is > a POLA violation. It's especially a POLA violation if

Re: CREATE SCHEMA ... CREATE DOMAIN support

I wrote: > 2. transformCreateSchemaStmtElements is of the opinion that it's > responsible for ordering the schema elements in a way that will work, > but it just about completely fails at that task. Ordering the objects > by kind is surely not sufficient, and adding CREATE DOMAIN will make > that

Re: Accessing other session's temp table

> Recently I saw a report and proposed fix here [0]. I did not dig into, just connection internets. Thanks! Oh, I missed it. Then I'll consider my issue closed and continue discussion in the older thread if there is something to discuss. Thanks a lot! -- best regards, Mikhail A. Gribkov e-m

Re: CREATE SCHEMA ... CREATE DOMAIN support

[ Looping in Peter E. for commentary on SQL-spec compatibility ] I spent some time looking at this patch, and came away with two main thoughts: 1. It doesn't make any sense to me to support CREATE DOMAIN within CREATE SCHEMA but not any of our other commands for creating types. It's not a consist

Re: [PATCH] Add sortsupport for range types and btree_gist

> On 30 Nov 2024, at 18:14, Bernd Helmle wrote: > > I don't like this. This smells like we use the wrong tool. Andrey had > the idea to use them because it looked as a compelling idea to check > whether sortsupport is used in the code path or not. > > Maybe we should just use a specific DEBU

Re: how to get MAJORVERSION in meson

so 30. 11. 2024 v 16:42 odesílatel jian he napsal: > On Fri, Nov 29, 2024 at 7:09 PM Pavel Stehule > wrote: > > > > > > > > pá 29. 11. 2024 v 10:42 odesílatel Pavel Stehule < > pavel.steh...@gmail.com> napsal: > >> > >> Hi > >> > >> I tried to add meson support to plpgsql_check. As template I us

Re: Unclear code - please elaborate

Dmitry Nikitin writes: > > https://github.com/postgres/postgres/blob/5d39becf8ba0080c98fee4b63575552f6800b012/src/backend/optimizer/prep/prepjointree.c#L3856 > bms_next_member() is allowed to return the zero as a valid value. Subsequent > rt_fetch() offsets that > zero to -1 which leads to the

Re: how to get MAJORVERSION in meson

On Fri, Nov 29, 2024 at 7:09 PM Pavel Stehule wrote: > > > > pá 29. 11. 2024 v 10:42 odesílatel Pavel Stehule > napsal: >> >> Hi >> >> I tried to add meson support to plpgsql_check. As template I used >> https://raw.githubusercontent.com/petere/plsh/refs/heads/meson/meson.build >> >> Unfortunat

Re: UUID v7

Andrey M. Borodin wrote: > I'm sending amendments addressing your review as a separate step in patch > set. Step 1 of this patch set is identical to v39. Some comments about the implementation of monotonicity: +/* + * Get the current timestamp with nanosecond precision for UUID generati

Re: [PATCH] Add sortsupport for range types and btree_gist

Hi Michael, Am Freitag, dem 29.11.2024 um 13:42 +0900 schrieb Michael Paquier: [...] > Any module that requires the module injection_points to be installed > can do a few things, none of them are done this way in this patch: > - Add EXTRA_INSTALL=src/test/modules/injection_points. > - You coul

Re: Pass ParseState as down to utility functions.

hi. ATExecAddOf DefineType ATPrepAlterColumnType ATExecAlterColumnType DefineDomain AlterType i changed the above function, so the above related function errors may print out error position. reason for change mainly because these functions have `typenameType(NULL, typeName, &targettypmod);` we wan

speedup ALTER TABLE ADD CHECK CONSTRAINT.

hi. attached patch trying to speedup ALTER TABLE ADD CHECK CONSTRAINT. demo: drop table if exists t7; create table t7 (a int not null, b int, c int); insert into t7 select g, g+1, g %100 from generate_series(1,1_000_000) g; create index on t7(a,b); alter table t7 add check (a > 0); patch: Time:

Re: Unclear code - please elaborate

On Sat, Nov 30, 2024 at 4:15 PM Dmitry Nikitin wrote: > > Hello , > > > https://github.com/postgres/postgres/blob/5d39becf8ba0080c98fee4b63575552f6800b012/src/backend/optimizer/prep/prepjointree.c#L3856 > bms_next_member() is allowed to return the zero as a valid value. Subsequent > rt_fetch()

[patch] Make "invalid record length at : expected at least 24, got 0" message less scary

Hi, we had another case on irc today were a user saw Postgres doing crash recovery due to an unclean shutdown and was very worried about a "invalid record length at : expected at least 24, got 0" message and went on to reindex all databases. This is also a frequent hit on Stack Overflow etc. AFAI

Re: Truncate logs by max_log_size

> > > Hi > > > +for (my $attempts = 0; $attempts < $max_attempts; $attempts++) > > +{ > > + eval { > > + $current_logfiles = slurp_file($node->data_dir . '/current_logfiles'); > > + }; > > + last unless $@; > > + usleep(100_000); > > +} > > > `usleep` in tap tests is usually a bad pattern. Do we ha

Re: Memory leak in WAL sender with pgoutput (v10~)

On 2024-Nov-30, Michael Paquier wrote: > After sleeping on that, and because the leak is minimal, I'm thinking > about just applying the fix only on HEAD and call it a day. This > changes the structure of Publication so as we use a char[NAMEDATALEN] > rather than a char*, avoiding the pstrdup(),

Unclear code - please elaborate

Hello , https://github.com/postgres/postgres/blob/5d39becf8ba0080c98fee4b63575552f6800b012/src/backend/optimizer/prep/prepjointree.c#L3856 bms_next_member() is allowed to return the zero as a valid value. Subsequent rt_fetch() offsets that zero to -1 which leads to the assertion down the code.