Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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.


pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group