On 11.07.23 07:52, Paul A Jungwirth wrote:
On Mon, Jul 10, 2023 at 8:06 AM Paul A Jungwirth
wrote:
On Mon, Jul 10, 2023 at 7:05 AM Peter Eisentraut wrote:
I'm not sure what value we would get from testing this with btree_gist,
but if we wanted to do that, then adding a new test file to the
On Mon, Jul 10, 2023 at 8:06 AM Paul A Jungwirth
wrote:
>
> On Mon, Jul 10, 2023 at 7:05 AM Peter Eisentraut wrote:
> > I'm not sure what value we would get from testing this with btree_gist,
> > but if we wanted to do that, then adding a new test file to the
> > btree_gist sql/ directory would
On Mon, Jul 10, 2023 at 7:05 AM Peter Eisentraut wrote:
> I'm not sure what value we would get from testing this with btree_gist,
> but if we wanted to do that, then adding a new test file to the
> btree_gist sql/ directory would seem reasonable to me.
>
> (I would make the test a little bit
On 09.07.23 03:21, Paul A Jungwirth wrote:
It seems to me that many of the test cases added in indexing.sql are
redundant with create_table.sql/alter_table.sql (or vice versa). Is
there a reason for this?
Yes, there is some overlap. I think that's just because there was
overlap before, and I
On Thu, Jul 6, 2023 at 1:03 AM Peter Eisentraut wrote:
> This looks all pretty good to me. A few more comments:
Thanks for the feedback! New patch attached here. Responses below:
> It seems to me that many of the test cases added in indexing.sql are
> redundant with
On 17.03.23 17:03, Paul Jungwirth wrote:
Thank you for taking a look! I did some research on the history of the
code here, and I think I understand Tom's concern about making sure the
index uses the same equality operator as the partition. I was confused
about his remarks about the opfamily,
Le vendredi 17 mars 2023, 17:03:09 CET Paul Jungwirth a écrit :
> I added the code about RTEqualStrategyNumber because that's what we need
> to find an equals operator when the index is GiST (except if it's using
> an opclass from btree_gist; then it needs to be BTEqual again). But then
> I
On 1/24/23 06:38, Ronan Dunklau wrote:
I've taken a look at the patch, and I'm not sure why you keep the restriction
on the Gist operator being of the RTEqualStrategyNumber strategy. I don't
think we have any other place where we expect those strategy numbers to
match. For hash it's different,
Le vendredi 16 décembre 2022, 06:11:49 CET Paul Jungwirth a écrit :
> On 12/15/22 16:12, Tom Lane wrote:
> >> This patch also requires the matching constraint columns to use equality
> >> comparisons (`(foo WITH =)`), so it is really equivalent to the existing
> >> b-tree rule.
> >
> > That's not
On 12/15/22 16:12, Tom Lane wrote:
This patch also requires the matching constraint columns to use equality
comparisons (`(foo WITH =)`), so it is really equivalent to the existing
b-tree rule.
That's not quite good enough: you'd better enforce that it's the same
equality operator (and same
Paul Jungwirth writes:
> It lets you create exclusion constraints on partitioned tables, similar
> to today's rules for b-tree primary keys & unique constraints:
> just as we permit a PK on a partitioned table when the PK's columns are
> a superset of the partition keys, so we
Hello Hackers,
I'm trying to get things going again on my temporal tables work, and
here is a small patch to move that forward.
It lets you create exclusion constraints on partitioned tables, similar
to today's rules for b-tree primary keys & unique constraints:
just as we permit
12 matches
Mail list logo
