On Tue, Feb 2, 2021 at 11:17 PM Tom Lane wrote:
>
> Dunno about refobjversion; I have my doubts that putting that info in
> pg_depend was a sane design choice at all. But from what I understand
> of it, wouldn't all deps on a given object necessarily have the same
> version?
Correct, assuming
Peter Eisentraut writes:
> I do wonder, however, under what circumstances code would be put into a
> situation where it would add the exact same dependency again, and also
> under what circumstances it would add a dependency between the same
> objects but a different deptype, and how that
On Tue, Feb 2, 2021 at 6:49 PM Peter Eisentraut
wrote:
>
> I do wonder, however, under what circumstances code would be put into a
> situation where it would add the exact same dependency again, and also
> under what circumstances it would add a dependency between the same
> objects but a
On 2021-01-22 16:42, Tom Lane wrote:
pg_depend
pg_shdepend
Yeah, this is noted in the patch's own regression tests.
Wouldn't it be possible to add primary keys to these two as well?
Neither of the existing indexes is suitable, not being unique.
We could imagine adding a unique index across
On 2021-02-01 15:24, Tom Lane wrote:
Peter Eisentraut writes:
On 2021-01-30 22:56, Tom Lane wrote:
Hmm, shouldn't there have been a catversion bump in there?
I suppose yes on the grounds that it introduces something new in a
freshly initdb-ed database. But I thought it wasn't necessary
Peter Eisentraut writes:
> On 2021-01-30 22:56, Tom Lane wrote:
>> Hmm, shouldn't there have been a catversion bump in there?
> I suppose yes on the grounds that it introduces something new in a
> freshly initdb-ed database. But I thought it wasn't necessary because
> there is no dependency
On 2021-01-30 22:56, Tom Lane wrote:
Peter Eisentraut writes:
Committed with your update, thanks.
Hmm, shouldn't there have been a catversion bump in there?
I suppose yes on the grounds that it introduces something new in a
freshly initdb-ed database. But I thought it wasn't necessary
Peter Eisentraut writes:
> Committed with your update, thanks.
Hmm, shouldn't there have been a catversion bump in there?
regards, tom lane
On 2021-01-21 18:15, Tom Lane wrote:
After reading the patch again, I have a couple more nits about comments,
which I'll just present as a proposed delta patch. Otherwise it's good.
I'll mark it RFC.
Committed with your update, thanks.
--
Peter Eisentraut
2ndQuadrant, an EDB company
On Fri, Jan 22, 2021, at 16:42, Tom Lane wrote:
>"Joel Jacobson" writes:
>> I ran this query (on a patched database) to see if there are still any
>> catalog tables without primary keys:
>> ...
>> pg_depend
>> pg_shdepend
>
>Yeah, this is noted in the patch's own regression tests.
Thanks. Looks
"Joel Jacobson" writes:
> I ran this query (on a patched database) to see if there are still any
> catalog tables without primary keys:
> ...
> pg_depend
> pg_shdepend
Yeah, this is noted in the patch's own regression tests.
> Wouldn't it be possible to add primary keys to these two as well?
Many thanks for excellent work!
I've tested the patch successfully.
I ran this query (on a patched database) to see if there are still any catalog
tables without primary keys:
SELECT
table_name
FROM information_schema.tables
WHERE table_schema = 'pg_catalog'
AND table_type = 'BASE TABLE'
Peter Eisentraut writes:
> On 2021-01-17 23:07, Tom Lane wrote:
>> I've reviewed this patch. It looks pretty solid to me, with a couple
>> trivial nits as mentioned below, and one bigger thing that's perhaps
>> in the category of bikeshedding. Namely, do we really want to prefer
>> using the
On 2021-01-17 23:07, Tom Lane wrote:
I've reviewed this patch. It looks pretty solid to me, with a couple
trivial nits as mentioned below, and one bigger thing that's perhaps
in the category of bikeshedding. Namely, do we really want to prefer
using the OID indexes as the primary keys? In
On 2021-01-18 18:23, Tom Lane wrote:
The reason I got interested in this right now is the nearby
discussion [1] about why findoidjoins misses some catalog
relationships and whether we should fix that and/or make its results
more readily accessible. I'd thought perhaps FK constraint entries
On 2021-01-18 00:35, Robert Haas wrote:
I don't have any complaint about labelling some of the unique indexes
as primary keys, but I think installing foreign keys that don't really
enforce anything may lead to confusion.
FWIW, "not enforced" constraints (such as foreign keys) is a feature
I'll post tomorrow the latest rebased patch with a summary of the issues.
Let's continue this in the foreign key array thread, as to not clutter this
thread.
Regards, Mark Rofail.
On Tue, Jan 19, 2021, 11:00 PM Joel Jacobson wrote:
> On Tue, Jan 19, 2021, at 18:25, Mark Rofail wrote:
> >Dear
On Tue, Jan 19, 2021, at 18:25, Mark Rofail wrote:
>Dear Joel,
>
>I would love to start working on this again, I tried to revive the patch again
>in 2019, however, I faced the same problems as >last time (detailed in the
>thread) and I didn't get the support I needed to continue with this patch.
Laurenz Albe writes:
> On Sun, 2021-01-17 at 17:07 -0500, Tom Lane wrote:
>> [...] do we really want to prefer
>> using the OID indexes as the primary keys? In most cases there's some
>> other index that seems to me to be what a user would think of as the
>> pkey, for example
Dear Joel,
I would love to start working on this again, I tried to revive the patch
again in 2019, however, I faced the same problems as last time (detailed in
the thread) and I didn't get the support I needed to continue with this
patch.
Are you willing to help rebase and finally publish this
On 1/19/21 11:46 AM, Laurenz Albe wrote:
> On Sun, 2021-01-17 at 17:07 -0500, Tom Lane wrote:
>> Peter Eisentraut writes:
>>> [ v2-0001-Add-primary-keys-and-unique-constraints-to-system.patch ]
>>
>> [...] do we really want to prefer
>> using the OID indexes as the primary keys? In most cases
On Mon, Jan 18, 2021, at 18:23, Tom Lane wrote:
> I realized that there's a stronger roadblock for
> treating catalog interrelationships as SQL foreign keys. Namely,
> that we always represent no-reference situations with a zero OID,
> whereas it'd have to be NULL to look like a valid foreign-key
On Sun, 2021-01-17 at 17:07 -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > [ v2-0001-Add-primary-keys-and-unique-constraints-to-system.patch ]
>
> [...] do we really want to prefer
> using the OID indexes as the primary keys? In most cases there's some
> other index that seems to me to
On Mon, Jan 18, 2021, at 19:33, Tom Lane wrote:
> On second thought, a catalog is overkill; it'd only be useful if the data
> could change after initdb, which this data surely cannot. The right way
> to expose such info to SQL is with a set-returning function reading a
> constant table in the C
I wrote:
> ... I still like the idea of marking OID relationships in the
> catalog headers though. Perhaps we should take Joel's suggestion
> of a new system catalog more seriously, and have genbki.pl populate
> such a catalog from info in the catalog header files.
On second thought, a catalog
Robert Haas writes:
> I don't have any complaint about labelling some of the unique indexes
> as primary keys, but I think installing foreign keys that don't really
> enforce anything may lead to confusion.
I'm not sure if I buy the "confusion" argument, but after thinking
about this more I
On Sat, Oct 3, 2020 at 9:27 AM Craig Ringer
wrote:
> Frankly I think we really need a way to mark FKs to be DISABLED or NOT
> CHECKED or something and a way to mark them as NOT VALID. Rsther than
> expecting uses to fiddle with the implementation triggers. But I don't think
> FKs on system
Peter Eisentraut writes:
> [ v2-0001-Add-primary-keys-and-unique-constraints-to-system.patch ]
I've reviewed this patch. It looks pretty solid to me, with a couple
trivial nits as mentioned below, and one bigger thing that's perhaps
in the category of bikeshedding. Namely, do we really want to
On 2020-10-03 08:40, Peter Eisentraut wrote:
Since we have ADD PRIMARY KEY USING INDEX, we can declare a primary key
for an existing index. So this doesn't have to affect the low-level
early bootstrapping. The attached patch adds those commands manually.
Another option might be to have the
On Tue, Oct 6, 2020 at 4:16 PM Andres Freund wrote:
> True, we don't create new ones that often. Still think that distributing
> such setup over fewer places is good. And it's not like there's only a
> handful of pkeys to start with. To me it makes more sense to add a
> DECLARE_PRIMARY_KEY in
Hi,
On 2020-10-06 15:31:16 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2020-10-03 08:40:31 +0200, Peter Eisentraut wrote:
> >> Since we have ADD PRIMARY KEY USING INDEX, we can declare a primary key for
> >> an existing index. So this doesn't have to affect the low-level early
> >>
Andres Freund writes:
> On 2020-10-03 08:40:31 +0200, Peter Eisentraut wrote:
>> Since we have ADD PRIMARY KEY USING INDEX, we can declare a primary key for
>> an existing index. So this doesn't have to affect the low-level early
>> bootstrapping. The attached patch adds those commands
Hi,
On 2020-10-03 08:40:31 +0200, Peter Eisentraut wrote:
> Since we have ADD PRIMARY KEY USING INDEX, we can declare a primary key for
> an existing index. So this doesn't have to affect the low-level early
> bootstrapping. The attached patch adds those commands manually. Another
> option
On Sun, 4 Oct 2020, 01:32 John Naylor, wrote:
>
> On Sat, Oct 3, 2020 at 9:27 AM Craig Ringer
> wrote:
> > So a big +1 from me for the idea. Especially if we ensure psql
> recognises when the relation 'oid' attribute has a declared PK and includes
> it in the column list.
>
> Oid has been in
On Sat, Oct 3, 2020 at 9:27 AM Craig Ringer
wrote:
> So a big +1 from me for the idea. Especially if we ensure psql recognises
when the relation 'oid' attribute has a declared PK and includes it in the
column list.
Oid has been in the normal column list since v12 when it stopped being a
system
On Sat, Oct 3, 2020 at 09:27:02PM +0800, Craig Ringer wrote:
>
>
> On Sat, 3 Oct 2020, 14:40 Peter Eisentraut,
> wrote:
>
> I saw someone ask once for a schema diagram of the system catalogs.
> Things like that have occasionally been produced manually, but they are
> not regularly
On Sat, 3 Oct 2020, 14:40 Peter Eisentraut, <
peter.eisentr...@2ndquadrant.com> wrote:
> I saw someone ask once for a schema diagram of the system catalogs.
> Things like that have occasionally been produced manually, but they are
> not regularly updated. That made me wonder, why can't we add
Services
From c9b1ff561dc7db045511a4da3cc87ecaac9c520b Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Sat, 3 Oct 2020 08:27:36 +0200
Subject: [PATCH] Add primary keys to system catalogs
For those system catalogs that have a unique index, make a primary key
constraint, using ALTER TABLE ... PRIMARY KEY USING IN
38 matches
Mail list logo
