Re: Re: Proposal: Store "timestamptz" of database creation on "pg_database"

From: Hannu Krosing <hannu(at)2ndquadrant(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>, Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Christopher Browne <cbbrowne(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: Proposal: Store "timestamptz" of database creation on "pg_database"
Date: 2013-01-09 10:32:41
Message-ID: 67vfmb41qi0dalm9v487sgeb.1357727561007@email.android.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

One thing i'd really like to be in this common object info catalog is DDL which created or altered the referenced object. 
If we additionally could make it possible to have ordinary triggers on this catalog it would solve most logical DDL replication problems

Hannu

Sent from Samsung Galaxy NotePeter Eisentraut <peter_e(at)gmx(dot)net> wrote:On Tue, 2013-01-08 at 17:17 -0500, Stephen Frost wrote:
> Seriously tho, the argument for not putting these things into the
> various individual catalogs is that they'd create bloat and these
> items
> don't need to be performant.  I would think that the kind of
> timestamps
> that we're talking about fall into the same data category as comments
> on
> tables.
>
> If there isn't a good reason for comments on objects to be off in a
> generic "this is for any kind of object" table, then perhaps we should
> move them into the appropriate catalog tables?

I think basic refactoring logic would support taking common things out
of the individual catalogs and keeping them in a common structure,
especially when they are for amusement only and not needed in any
critical paths.  All the ALTER command refactoring and so on that's been
going on is also moving into the direction that for data definition
management, there should be mainly one kind of object with a few
variants here and there.

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2013-01-09 11:22:06 Re: Re: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap [Review]
Previous Message Christoph Berg 2013-01-09 10:21:44 Re: PL/perl should fail on configure, not make