Bruce Momjian writes:
> How do you handle dump/restore? Is it preserved?
I would think not.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Tom Lane wrote:
> Pavel Stehule writes:
> > this my proposal is very simple. It help to people who have to manage
> > large or complex database system. Important data are date of creating
> > and date of altering tables and stored procedures. These data cannot
> > be modified by user, so implement
Robert Haas wrote:
> Making pg_class and pg_proc tables larger hurts run-time
performance,
> potentially. Making a separate table only slows down DDL
operations,
> which are much less frequent.
Copying the pg_class table, with oids and indexes, with and without
the addition of one timestamp co
Robert Haas writes:
> On Tue, Apr 14, 2009 at 10:27 AM, Kevin Grittner
>> Yeah, if it would be too heavy to add a timestamp column or two to
>> pg_class and maybe one or two others, why is it better to add a whole
>> new table to maintain in parallel -- with it's own primary key,
>> foreign keys (
On Tue, Apr 14, 2009 at 10:27 AM, Kevin Grittner
wrote:
> Pavel Stehule wrote:
>> I though about it too. But I am not sure, if this isn't too
>> complicated solution for simple task. If I thing little bit more -
>> main important is timestamp of last change.
>
> Yeah, if it would be too heavy to
Pavel Stehule wrote:
> I though about it too. But I am not sure, if this isn't too
> complicated solution for simple task. If I thing little bit more -
> main important is timestamp of last change.
Yeah, if it would be too heavy to add a timestamp column or two to
pg_class and maybe one or two
2009/4/14 Josh Berkus :
>
>>> - what if I need to know about operators, operator classes, schemas, etc
>>> etc
>>
>> Fine, let's log this info for those too (or else decide they're too
>> obscure and don't - pg_class and pg_proc are certainly the most
>> interesting cases).
>
> I would suggest put
On Mon, Apr 13, 2009 at 7:06 PM, Tom Lane wrote:
> Josh Berkus writes:
>> I would suggest putting this info in a separate table, pg_change. It
>> would have oid, catalog, user_changed, changed_on. That way we could
>> simply keep the data for all objects which have an OID.
>
> That makes more s
Josh Berkus writes:
> I would suggest putting this info in a separate table, pg_change. It
> would have oid, catalog, user_changed, changed_on. That way we could
> simply keep the data for all objects which have an OID.
That makes more sense to me --- it would easily extend to all cases
and w
- what if I need to know about operators, operator classes, schemas, etc
etc
Fine, let's log this info for those too (or else decide they're too
obscure and don't - pg_class and pg_proc are certainly the most
interesting cases).
I would suggest putting this info in a separate table, pg_chan
Pavel Stehule writes:
> this my proposal is very simple. It help to people who have to manage
> large or complex database system. Important data are date of creating
> and date of altering tables and stored procedures. These data cannot
> be modified by user, so implementation doesn't need any new
2009/4/13 Kevin Grittner :
> Pavel Stehule wrote:
>> Important data are date of creating and date of altering tables
>> and stored procedures. These data cannot be modified by user, so
>> implementation doesn't need any new statements.
>>
>> Notes, objections?
>
> This feature has been present in
Pavel Stehule wrote:
> Important data are date of creating and date of altering tables
> and stored procedures. These data cannot be modified by user, so
> implementation doesn't need any new statements.
>
> Notes, objections?
This feature has been present in other database products I've used,
On Mon, Apr 13, 2009 at 1:32 PM, Tom Lane wrote:
> Pavel Stehule writes:
>> this my proposal is very simple. It help to people who have to manage
>> large or complex database system. Important data are date of creating
>> and date of altering tables and stored procedures. These data cannot
>> be
On Mon, Apr 13, 2009 at 2:32 PM, Tom Lane wrote:
> Pavel Stehule writes:
>> this my proposal is very simple. It help to people who have to manage
>> large or complex database system. Important data are date of creating
>> and date of altering tables and stored procedures. These data cannot
>> be
Tom Lane wrote:
> Pavel Stehule writes:
>> this my proposal is very simple. It help to people who have to
>> manage large or complex database system. Important data are date of
>> creating and date of altering tables and stored procedures. These
>> data cannot be modified by user, so implementat
2009/4/13 Tom Lane :
> Pavel Stehule writes:
>> this my proposal is very simple. It help to people who have to manage
>> large or complex database system. Important data are date of creating
>> and date of altering tables and stored procedures. These data cannot
>> be modified by user, so implemen
17 matches
Mail list logo
