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
Hello,
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
statements.
Notes, ob
18 matches
Mail list logo
