Peter Eisentraut writes:
> On 28.11.24 07:34, Michael Paquier wrote:
>> - "WHERE p.prokind = 'a'\n",
>> + "WHERE p.prokind = "
>> CppAsString2(PROKIND_AGGREGATE) "\n",
> I noticed something here. If the sy
On Sat, Nov 23, 2024 at 10:58 AM Heikki Linnakangas wrote:
> Hmm, so this would replace the maybeSleepingOnInterrupts bitmask I
> envisioned. Makes a lot of sense. If it's a single bit though, that
> means that you'll still get woken up by interrupts that you're not
> waiting for. Maybe that's fin
> On 2 Dec 2024, at 08:37, Peter Eisentraut wrote:
> the current structure assumes that the C character literal syntax used by the
> PROKIND_* and other symbols happens to be the same as the SQL string literal
> syntax required in those queries, which is just an accident.)
I'm not sure I would
On 19.11.24 17:27, Peter Eisentraut wrote:
On 14.11.24 09:04, Peter Eisentraut wrote:
You can also reproduce this with things that are not strings with
collations. You just need to find a type that has values that are
"equal" but "distinct", which is not common, but it exists, for
example 0.0
On Mon, Dec 02, 2024 at 11:47:09AM +0530, Amit Kapila wrote:
> We already have PGOutputData->cachectx which could be used for it. I
> think we should be able to reset such a context when we are
> revalidating the publications. Even, if we want a new context for some
> localized handling, we should
>>
>> typo:
>> There are none. During initializion all settings are assigned a non-null
>> value.
>> 5.2.16. Null Values in Partiton Keys
>> As noted in the synatx chapter, a null value literal is written using
>> the NULL keyword. Its type is the pseudo-type unknown but can be cast
>> to any conc
On Mon, Dec 2, 2024 at 7:19 AM Michael Paquier wrote:
>
> On Sat, Nov 30, 2024 at 09:28:31AM +0100, Alvaro Herrera wrote:
> > I'm not sure about your proposed fix. Isn't it simpler to have another
> > memory context which we can reset instead of doing list_free_deep()? It
> > doesn't have to be
On Fri, Nov 29, 2024 at 5:20 PM David Rowley wrote:
>
> The reason I don't think is possible is that we have no infrastructure
> that allows us to tag functions or operators so that non-null input(s)
> mean non-null outputs. We only have strict, which means null input
> means null output. That's
On 29/11/2024 14:28, David Rowley wrote:
On Fri, 29 Nov 2024 at 19:36, Andrei Lepikhov wrote:
1. Thread reference in the patch comment doesn't work.
2. May it be possible to move remove_useless_groupby_columns in the
second commit? It would be easier to review the differences.
For #1, I rewro
On Fri, Nov 29, 2024 at 4:05 PM Hayato Kuroda (Fujitsu)
wrote:
>
> 02. maybe_advance_nonremovable_xid
>
> ```
> +case RCI_REQUEST_PUBLISHER_STATUS:
> +request_publisher_status(data);
> +break;
> ```
>
> I think the part is not reachable because the transit
> RCI_REQ
On Wed, Nov 27, 2024 at 5:45 PM Richard Guo wrote:
> I ended up using 'under the same lowest nulling outer join' to
> keep consistent with the wording used elsewhere. Please see the
> updated patch attached.
Commit e032e4c7d computes the nullingrel data for each leaf RTE, and
we can leverage tha
Michael Paquier writes:
> If I'm parsing the spec right, the doc mentions in its 5)~6) of the
> syntax rules in CREATE SCHEMA that non-schema-qualified objects should
> use the new schema name defined in the CREATE SCHEMA query. So that
> pretty much settles the rules to use when having a new obj
On Sat, Nov 30, 2024 at 09:28:31AM +0100, Alvaro Herrera wrote:
> I'm not sure about your proposed fix. Isn't it simpler to have another
> memory context which we can reset instead of doing list_free_deep()? It
> doesn't have to be a global memory context -- since this is not
> reentrant and not
On Sun, Dec 01, 2024 at 05:30:20PM -0500, Tom Lane wrote:
> Which certainly begs the question of how smart their re-ordering
> algorithm is, or what they do about ambiguity between new and existing
> objects.
Perhaps because they are able to track efficiently all schema
references, like checking t
Michel Pelletier writes:
> On Mon, Nov 18, 2024 at 7:42 PM Andy Fan wrote:
>
> Andy Fan writes:
>
> >
> > make check-world passed after applying this patch.
>
> v2 changes the places of Assert, which is missed in v1 by mistakes.
>
> I'm not an expert in this end of the code but it looks cor
ne 1. 12. 2024 v 22:24 odesílatel Pavel Stehule
napsal:
>
>
> ne 1. 12. 2024 v 21:16 odesílatel Pavel Stehule
> napsal:
>
>>
>>
>> ne 1. 12. 2024 v 21:06 odesílatel Pavel Stehule
>> napsal:
>>
>>>
>>>
>>> ne 1. 12. 2024 v 19:23 odesílatel Andres Freund
>>> napsal:
>>>
Hi,
On 202
I wrote:
> I looked at DB2's reference page:
> https://www.ibm.com/docs/en/db2/11.5?topic=statements-create-schema
Oh, how did I forget Oracle?
https://docs.oracle.com/en/database/oracle/oracle-database/23/sqlrf/CREATE-SCHEMA.html
Theirs is restricted to CREATE TABLE, CREATE VIEW, and GRANT; als
I wrote:
> So after digging into it, I realized that I'd been completely misled
> by setop_fill_hash_table's not failing while reading the first input.
> That's not because the code was correct, it was because none of our
> test cases manage to reach TupleHashTableMatch() while reading the
> first
ne 1. 12. 2024 v 21:16 odesílatel Pavel Stehule
napsal:
>
>
> ne 1. 12. 2024 v 21:06 odesílatel Pavel Stehule
> napsal:
>
>>
>>
>> ne 1. 12. 2024 v 19:23 odesílatel Andres Freund
>> napsal:
>>
>>> Hi,
>>>
>>> On 2024-12-01 19:11:05 +0100, Pavel Stehule wrote:
>>> > ne 1. 12. 2024 v 19:05 odesíl
ne 1. 12. 2024 v 21:06 odesílatel Pavel Stehule
napsal:
>
>
> ne 1. 12. 2024 v 19:23 odesílatel Andres Freund
> napsal:
>
>> Hi,
>>
>> On 2024-12-01 19:11:05 +0100, Pavel Stehule wrote:
>> > ne 1. 12. 2024 v 19:05 odesílatel Andres Freund
>> napsal:
>> > > If it fails due to libintl you're like
Hi all,
When looking at the date_trunc function, I noticed that it wasn't
rejecting invalid units if the value was infinite. It's slightly
annoying to fix this, but we already do something very similar for
date_part. I have attached a patch that would fix this issue, let me
know if you think it's
ne 1. 12. 2024 v 19:23 odesílatel Andres Freund napsal:
> Hi,
>
> On 2024-12-01 19:11:05 +0100, Pavel Stehule wrote:
> > ne 1. 12. 2024 v 19:05 odesílatel Andres Freund
> napsal:
> > > If it fails due to libintl you're likely missing the libintl headers
> that
> > > the
> > > windows build was b
> On Mon, Dec 04, 2023 at 10:18:09PM -0600, Nathan Bossart wrote:
>
> Thanks for the new patch. I am hoping to spend much more time on this in
> the near future...
Hi,
The patch looks interesting, having around 8% improvement on that sounds
attractive. Nathan, do you plan to come back to it and
Hi,
On 2024-12-01 19:11:05 +0100, Pavel Stehule wrote:
> ne 1. 12. 2024 v 19:05 odesílatel Andres Freund napsal:
> > If it fails due to libintl you're likely missing the libintl headers that
> > the
> > windows build was built against.
> >
>
> This file is part of PostgreSQL's header files from
ne 1. 12. 2024 v 19:05 odesílatel Andres Freund napsal:
> Hi,
>
> On 2024-12-01 18:52:48 +0100, Pavel Stehule wrote:
> > Did somebody test compilation of any extension on the WIN platform by
> using
> > meson?
> >
> > I prepared meson.build
> > https://github.com/orafce/orafce/blob/master/meson.b
Hi,
On 2024-12-01 18:52:48 +0100, Pavel Stehule wrote:
> Did somebody test compilation of any extension on the WIN platform by using
> meson?
>
> I prepared meson.build
> https://github.com/orafce/orafce/blob/master/meson.build
>
> I tested it successfully on Linux.
>
> But it fails on Windows
Hi
Did somebody test compilation of any extension on the WIN platform by using
meson?
I prepared meson.build
https://github.com/orafce/orafce/blob/master/meson.build
I tested it successfully on Linux.
But it fails on Windows - a lot of compilation fails on missing libintl.h
DOCDIR = C:/PROGRA~
Hi!
This, ON CONFLICT DO SELECT, is a feature I have wished for ever since
ON CONFLICT was added to PostgreSQL and I have worked with several code
bases where it would have been useful. So now I finally got round to
revive and rebase Marko's old patch.
Marko originally posted the patch back
On Mon, Nov 18, 2024 at 7:42 PM Andy Fan wrote:
> Andy Fan writes:
>
> >
> > make check-world passed after applying this patch.
>
> v2 changes the places of Assert, which is missed in v1 by mistakes.
>
I'm not an expert in this end of the code but it looks correct to me, my
only comment would b
Sergei Kornilov writes:
> Hello!
> Thanks for the patch, but I think using SPI is still not allowed here:
> https://www.postgresql.org/message-id/9878.1511970441%40sss.pgh.pa.us
Yeah, if you want to do this you need to code the catalog lookup in
C. SPI just adds too many variables to what will
jian he writes:
> On Sun, Dec 1, 2024 at 1:53 PM Tom Lane wrote:
>> (I'd be curious to know how other major implementations handle
>> this. Are we the only implementation that ever read the spec
>> that way?)
> quote from
> https://learn.microsoft.com/en-us/sql/t-sql/statements/create-schema-
On Nov 29, 2024, at 15:39, Noah Misch wrote:
> Then packagers who are taking the risk of not rebuilding every time will have
> 3 months to prepare, not the 3 days we're currently giving. The point about
> "well-known extensions" is based on my practice of grepping PGXN. That would
> not have fo
Hello!
Thanks for the patch, but I think using SPI is still not allowed here:
https://www.postgresql.org/message-id/9878.1511970441%40sss.pgh.pa.us
> if it uses SPI for sub-operations of ALTER TABLE I think that is sufficient
> reason to reject it out of hand.
regards, Sergei
On Sun, Dec 1, 2024 at 10:15 AM yuansong wrote:
> I confirmed that there's an issue with prematurely ending the loop. When I
> enter the if (unlikely(result == 0 && key->scantid != NULL)) block, low = 2,
> mid = 4, and high = 4. At this point, the offset of insertstate->postingoff
> is obtained
sorry， I write something wrong。
I confirmed that there's an issue with prematurely ending the loop. When I
enter the if (unlikely(result == 0 && key->scantid != NULL)) block, low = 2,
mid = 4, and high = 4. At this point, the offset of insertstate->postingoff is
obtained from the mid value, whi
I confirmed that there's an issue with prematurely ending the loop. When I
enter the if (unlikely(result == 0 && key->scantid != NULL)) block, low = 2,
mid = 4, and high = 4. At this point, the offset of insertstate->postingoff is
obtained from the mid value, which is 3. However, the loop doesn'
Hello hackers,
Please take a look at the November report on buildfarm failures:
# SELECT br, count(*) FROM failures WHERE dt >= '2024-11-01' AND
dt < '2024-12-01' GROUP BY br;
REL_12_STABLE: 8
REL_13_STABLE: 8
REL_14_STABLE: 13
REL_15_STABLE: 10
REL_16_STABLE: 37
REL_17_STABLE: 29
master: 42
--
On Sun, Dec 1, 2024 at 1:53 PM Tom Lane wrote:
>
> 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 appe
38 matches
Mail list logo
