On Tue, Jan 21, 2025 at 03:23:31PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > I did write a patch in Novemer 2023 to pass the dimension to the layers
> > that needed it, but it was considered too much code compared to its
> > value:
> > https://www.postgresql.org/message-id/zvwi_ozt8z9
I wrote:
> I wonder if we should try to fix the GIN AM to avoid that.
> The column being indexed is of an array type in these cases, but the
> index entries aren't. It seems inconsistent that it sets up the index
> column's attndims and atttypid this way.
Ah, I see the problem: it's not GIN's fau
Bruce Momjian writes:
> I did write a patch in Novemer 2023 to pass the dimension to the layers
> that needed it, but it was considered too much code compared to its
> value:
> https://www.postgresql.org/message-id/zvwi_ozt8z9mc...@momjian.us
Ah, I'd forgotten that discussion. It looks lik
On Sun, Jan 19, 2025 at 06:47:14PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > Using the queries in that URL, I see:
>
> > CREATE TABLE test (data integer, data_array integer[5][5]);
> > CREATE TABLE test2 (LIKE test);
> > CREATE TABLE test3 AS SELECT * FROM test;
> > SELEC
On Sun, Jan 19, 2025 at 07:07:03PM -0500, Tom Lane wrote:
> Michael Paquier writes:
> > Small question on this one: would it be worth adding a check in
> > sanity_check.sql for bumpy values?
>
> Yeah, I didn't bother with a regression test in this draft, but
> we should likely have one. Or was y
Michael Paquier writes:
> Small question on this one: would it be worth adding a check in
> sanity_check.sql for bumpy values?
Yeah, I didn't bother with a regression test in this draft, but
we should likely have one. Or was your point something different?
regards, tom l
On Sun, Jan 19, 2025 at 06:47:14PM -0500, Tom Lane wrote:
> I looked at getting a better result here and decided that it didn't
> look very promising. pg_dump uses format_type() to build the type
> name to put in CREATE TABLE, and that doesn't have access to attndims.
Small question on this one:
Bruce Momjian writes:
> Using the queries in that URL, I see:
> CREATE TABLE test (data integer, data_array integer[5][5]);
> CREATE TABLE test2 (LIKE test);
> CREATE TABLE test3 AS SELECT * FROM test;
> SELECT relname, attndims
> FROM pg_class JOIN pg_attribute ON (
On Thu, Dec 26, 2024 at 06:07:45PM -0500, Bruce Momjian wrote:
> On Thu, Dec 26, 2024 at 05:08:36PM -0500, Tom Lane wrote:
>> I think removal is not happening. The documentation for attndims
>> already says
>>
>> Number of dimensions, if the column is an array type; otherwise
>> 0. (Prese
On Thu, Dec 26, 2024 at 05:08:36PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > So, if users are referencing attndims and the values are not accurate,
> > how useful are they? I was suggesting removal so people would stop
> > relying on inaccurate information, or we correct attndims to be
>
Bruce Momjian writes:
> So, if users are referencing attndims and the values are not accurate,
> how useful are they? I was suggesting removal so people would stop
> relying on inaccurate information, or we correct attndims to be
> accurate. Allowing people to continue relying on inaccurate info
On Mon, Dec 23, 2024 at 01:56:24PM +0900, Michael Paquier wrote:
> On Thu, Dec 12, 2024 at 03:40:32PM +0800, jian he wrote:
> > remove pg_type typndims column patch attached.
>
> FWIW, I have been paying more attention to applications that may use
> this attribute and bumped into quite a few cases
On Thu, Dec 12, 2024 at 03:40:32PM +0800, jian he wrote:
> remove pg_type typndims column patch attached.
FWIW, I have been paying more attention to applications that may use
this attribute and bumped into quite a few cases that use quals based
on (t.typndims > 0 AND t.typbasetype > 0) to check th
hi.
remove pg_type typndims column patch attached.
From 656fc3bec597f65368a7bd1cdee183865d4070e7 Mon Sep 17 00:00:00 2001
From: jian he
Date: Thu, 12 Dec 2024 15:27:34 +0800
Subject: [PATCH v3 1/1] remove pg_type typndims
discussion: https://postgr.es/m/CACJufxH0RxsxUQnAT2AVG08JFpA3C60L91_cEMM8JQ
On Wed, Dec 11, 2024 at 12:15:51AM -0500, Tom Lane wrote:
> Michael Paquier writes:
> > FWIW, my first thought after reading this paragraph is that you sound
> > too dramatic here, especially after looking at codesearch to note that
> > the PHP core code stores attndims but does not actually use i
Michael Paquier writes:
> FWIW, my first thought after reading this paragraph is that you sound
> too dramatic here, especially after looking at codesearch to note that
> the PHP core code stores attndims but does not actually use it.
It appeared to me that it fetches it in order to return it in
On Thu, Dec 05, 2024 at 06:34:31PM -0500, Tom Lane wrote:
> You have a mighty optimistic view of what will happen. I predict
> that if we do step (1), exactly nothing will happen in applications,
> and step (2) will remain just as painful for them. (Assuming that
> we remember to do step (2), whi
per above discussion:
for TupleDescInitEntry, TupleDescInitBuiltinEntry, I didn't change the
signature of it.
but i added:
if (attdim != 0)
elog(ERROR, "attdim should be zero");
otherwise it may have "unused parameter" warnings?
for the same reason in TypeCreate, I added:
if (typ
Bruce Momjian writes:
> How about if we set attndims & typndims to zero in PG 18, and mention
> that these fields are deprecated in the release notes. Then, in a few
> years, we can remove the columns since interfaces hopefully would have
> removed the useless references to the columns.
You have
On Thu, Dec 5, 2024 at 12:03:30PM -0500, Bruce Momjian wrote:
> On Thu, Dec 5, 2024 at 12:00:30PM -0500, Tom Lane wrote:
> > Bruce Momjian writes:
> > > On Thu, Dec 5, 2024 at 11:33:22AM -0500, Tom Lane wrote:
> > >> I don't think we can do this as presented. Maybe we could do
> > >> something
On Thu, Dec 5, 2024 at 12:00:30PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Thu, Dec 5, 2024 at 11:33:22AM -0500, Tom Lane wrote:
> >> I don't think we can do this as presented. Maybe we could do
> >> something like constrain the stored value to be only 0 or 1,
> >> but how much doe
Bruce Momjian writes:
> On Thu, Dec 5, 2024 at 11:33:22AM -0500, Tom Lane wrote:
>> I don't think we can do this as presented. Maybe we could do
>> something like constrain the stored value to be only 0 or 1,
>> but how much does that improve matters?
> Well, then the question becomes will we r
On Thu, Dec 5, 2024 at 11:33:22AM -0500, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2024-Dec-05, Kirill Reshke wrote:
> >> I see no open items in this thread. Are there any issues about v1?
>
> > Should we leave TupleDescInitEntry()'s API alone, to avoid breaking the
> > compilation of ever
Alvaro Herrera writes:
> On 2024-Dec-05, Kirill Reshke wrote:
>> I see no open items in this thread. Are there any issues about v1?
> Should we leave TupleDescInitEntry()'s API alone, to avoid breaking the
> compilation of every extension in the world?
I fear the howls of pain from extension aut
On 2024-Dec-05, Kirill Reshke wrote:
> On Fri, 20 Sept 2024 at 07:11, jian he wrote:
> > attached patch removes attndims and typndims entirely.
>
> LGTM?
> I see no open items in this thread. Are there any issues about v1?
Should we leave TupleDescInitEntry()'s API alone, to avoid breaking the
On Fri, 20 Sept 2024 at 07:11, jian he wrote:
> attached patch removes attndims and typndims entirely.
LGTM?
I see no open items in this thread. Are there any issues about v1?
--
Best regards,
Kirill Reshke
On 2024-09-20 Fr 12:38 AM, Tom Lane wrote:
Michael Paquier writes:
On Fri, Sep 20, 2024 at 11:51:49AM +0800, Junwang Zhao wrote:
Should you also bump the catalog version?
No need to worry about that when sending a patch because committers
take care of that when merging a patch into the tree
On Fri, Sep 20, 2024 at 10:11:00AM +0800, jian he wrote:
> On Wed, Sep 18, 2024 at 10:35 PM jian he wrote:
> >
> > > The last time this was discussed, I think the conclusion was
> > > we should remove attndims and typndims entirely on the grounds
> > > that they're useless. I certainly don't see
Hi Tom and Michael,
On Fri, Sep 20, 2024 at 12:38 PM Tom Lane wrote:
>
> Michael Paquier writes:
> > On Fri, Sep 20, 2024 at 11:51:49AM +0800, Junwang Zhao wrote:
> >> Should you also bump the catalog version?
>
> > No need to worry about that when sending a patch because committers
> > take car
Michael Paquier writes:
> On Fri, Sep 20, 2024 at 11:51:49AM +0800, Junwang Zhao wrote:
>> Should you also bump the catalog version?
> No need to worry about that when sending a patch because committers
> take care of that when merging a patch into the tree. Doing that in
> each patch submitted
On Fri, Sep 20, 2024 at 11:51:49AM +0800, Junwang Zhao wrote:
> Should you also bump the catalog version?
No need to worry about that when sending a patch because committers
take care of that when merging a patch into the tree. Doing that in
each patch submitted just creates more conflicts and wo
On Fri, Sep 20, 2024 at 10:11 AM jian he wrote:
>
> On Wed, Sep 18, 2024 at 10:35 PM jian he wrote:
> >
> > > The last time this was discussed, I think the conclusion was
> > > we should remove attndims and typndims entirely on the grounds
> > > that they're useless. I certainly don't see a poin
On Wed, Sep 18, 2024 at 10:35 PM jian he wrote:
>
> > The last time this was discussed, I think the conclusion was
> > we should remove attndims and typndims entirely on the grounds
> > that they're useless. I certainly don't see a point in adding
> > more logic that could give the misleading imp
On Wed, Sep 18, 2024 at 10:10 PM Tom Lane wrote:
>
> jian he writes:
> > Can we error out at the stage "create table", "create domain"
> > time if the attndims or typndims is larger than MAXDIM (6) ?
>
> The last time this was discussed, I think the conclusion was
> we should remove attndims and
jian he writes:
> Can we error out at the stage "create table", "create domain"
> time if the attndims or typndims is larger than MAXDIM (6) ?
The last time this was discussed, I think the conclusion was
we should remove attndims and typndims entirely on the grounds
that they're useless. I certa
35 matches
Mail list logo
