2013/1/3 Stephen Frost sfr...@snowman.net:
* Robert Haas (robertmh...@gmail.com) wrote:
Well, IMHO, there is no need for any syntax change at all. CREATE
TABLE and CREATE DATABASE should just record the creation time
somewhere, and that's all. If you dump-and-reload, the creation time
On 12/28/2012 03:14 AM, Stephen Frost wrote:
...
I agree that what I was suggesting would be possible to implement with
event triggers, but I see that as a rather advanced feature that most
users aren't going to understand or implement. At the same time, those
more novice users are likely to
2013/1/3 Hannu Krosing ha...@krosing.net:
On 12/28/2012 03:14 AM, Stephen Frost wrote:
...
I agree that what I was suggesting would be possible to implement with
event triggers, but I see that as a rather advanced feature that most users
aren't going to understand or implement. At the same
--On 2. Januar 2013 23:04:43 -0500 Robert Haas robertmh...@gmail.com
wrote:
TBH, I don't think anyone has any business changing the creation
timestamp. Ever. For me, the fact that pg_dump wouldn't preserve
this information would be a feature, not a bug. I mostly meant to
point out that
On 01/03/2013 05:04 AM, Robert Haas wrote:
O
Yeah, I don't think this is really a problem. I would expect the psql
support for this feature to be not a whole lot more complicated than
that. Sure, it might be more than 5 lines of raw code if it requires
an additional version of some query for
* Fabrízio de Royes Mello (fabriziome...@gmail.com) wrote:
The attached patch add a new column into 'pg_database' called 'datcreated'
to store the timestamp of database creation.
Please use hard-tabs (not spaces) and the column should come before the
variable length records (see the comment in
* Hannu Krosing (ha...@krosing.net) wrote:
If what you want is something close to current unix file time
semantics (ctime, mtime, atime) then why not just create a function
to look up these attributes on database directory and/or database
files ?
Because, as noted before, those aren't always
On Thu, Jan 3, 2013 at 11:13 AM, Stephen Frost sfr...@snowman.net wrote:
* Fabrízio de Royes Mello (fabriziome...@gmail.com) wrote:
The attached patch add a new column into 'pg_database' called
'datcreated'
to store the timestamp of database creation.
Please use hard-tabs (not spaces) and
On Thu, Jan 3, 2013 at 11:33 AM, Fabrízio de Royes Mello
fabriziome...@gmail.com wrote:
On Thu, Jan 3, 2013 at 11:13 AM, Stephen Frost sfr...@snowman.net wrote:
* Fabrízio de Royes Mello (fabriziome...@gmail.com) wrote:
The attached patch add a new column into 'pg_database' called
* Fabrízio de Royes Mello (fabriziome...@gmail.com) wrote:
On Thu, Jan 3, 2013 at 11:13 AM, Stephen Frost sfr...@snowman.net wrote:
Please use hard-tabs (not spaces) and the column should come before the
variable length records (see the comment in pg_database.h).
You all right... I fixed
On 1/2/13 11:08 PM, Fabrízio de Royes Mello wrote:
The attached patch add a new column into 'pg_database' called
'datcreated' to store the timestamp of database creation.
If this feature is approved I could extend it to add a column into
'pg_class' to store creation timestamp too.
While I'm
2013/1/3 Peter Eisentraut pete...@gmx.net:
On 1/2/13 11:08 PM, Fabrízio de Royes Mello wrote:
The attached patch add a new column into 'pg_database' called
'datcreated' to store the timestamp of database creation.
If this feature is approved I could extend it to add a column into
'pg_class'
On Thu, Jan 3, 2013 at 9:18 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
2013/1/3 Peter Eisentraut pete...@gmx.net:
On 1/2/13 11:08 PM, Fabrízio de Royes Mello wrote:
The attached patch add a new column into 'pg_database' called
'datcreated' to store the timestamp of database creation.
Peter Eisentraut escribió:
If we're going to store object creation time, I think we should do it
for all objects, stored in a separate catalog, like pg_depend or
pg_description, keyed off classid, objectid. And have a simple C
function to call to update the information stored there.
+1
We
On Thu, Jan 3, 2013 at 11:41 AM, Stephen Frost sfr...@snowman.net wrote:
* Fabrízio de Royes Mello (fabriziome...@gmail.com) wrote:
On Thu, Jan 3, 2013 at 11:13 AM, Stephen Frost sfr...@snowman.net
wrote:
Please use hard-tabs (not spaces) and the column should come before the
variable
On Thu, Jan 3, 2013 at 12:30 PM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Peter Eisentraut escribió:
If we're going to store object creation time, I think we should do it
for all objects, stored in a separate catalog, like pg_depend or
pg_description, keyed off classid, objectid.
Fabrízio de Royes Mello escribió:
As Peter said we can start add it for a few commands in one release (maybe
first for shared objects) and then for a few more commands in a next
release, and next... until we cover all commands...
No, he was describing a pessimistic scenario that he doesn't
On Thu, Jan 3, 2013 at 2:06 AM, Stephen Frost sfr...@snowman.net wrote:
I'd be alright with this also, tbh. Not preserving such information
across pg_dump's wouldn't really be all *that* much of a loss.
I think it would be mandatory for pg_dump not to restore this info
actually. A fair amount
On Wed, Dec 26, 2012 at 11:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
This has been debated, and rejected, before.
To mention just one problem, are we going to add nonstandard,
non-backwards-compatible syntax to every single kind of CREATE to allow
pg_dump to preserve the creation dates?
Robert Haas robertmh...@gmail.com writes:
[ on creation timestamps ]
I know this has been discussed and rejected before, but I find that
rejection to be wrong-headed. I have repeatedly been asked, with
levels of exasperation ranging from mild to homicidal, why we don't
have this feature, and
* Robert Haas (robertmh...@gmail.com) wrote:
Well, IMHO, there is no need for any syntax change at all. CREATE
TABLE and CREATE DATABASE should just record the creation time
somewhere, and that's all. If you dump-and-reload, the creation time
changes. Deal with it, or hack your catalogs if
* Tom Lane (t...@sss.pgh.pa.us) wrote:
If I believed that it would be a hundred-line patch, and would *stay*
a hundred-line patch, I'd be fine with it. But it won't. I will
bet a very fine dinner that the feature wouldn't get out the door
before there would be demands for pg_dump support.
On Wed, Jan 2, 2013 at 9:12 PM, Stephen Frost sfr...@snowman.net wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
If I believed that it would be a hundred-line patch, and would *stay*
a hundred-line patch, I'd be fine with it. But it won't. I will
bet a very fine dinner that the feature
* Robert Haas robertmh...@gmail.com wrote:
I know this has been discussed and rejected before, but I find that
rejection to be wrong-headed. I have repeatedly been asked, with
levels of exasperation ranging from mild to homicidal, why we don't
have this feature, and I have no good answer. If
Fabrízio de Royes Mello fabriziome...@gmail.com writes:
Event triggers don't cover CREATE DATABASE statement.
The reason why is because you create Event Triggers in a specific
database and they only get run when you happen to be connected to that
specific database.
So for example say you
Dimitri,
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
I personnaly think that given a good documentation coverage having Event
Trigger on global objects could be useful enough, even if you would have
to install them in every database when you want them to fire no matter
what.
I
Stephen Frost sfr...@snowman.net writes:
I disagree. If we're going to have what are essentially 'global' event
triggers, then they should go into a shared catalog- the user shouldn't
be required to install them everywhere to get coverage. In addition,
I understand your view point, and if we
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
It sounds to me like either autonomous transaction with the capability
to run the independant transaction in another database, or some dblink
creative use case. Another approach would be to get plproxy into core
as a Foreign Data Wrapper for
Stephen Frost sfr...@snowman.net writes:
Apparently I've managed to miss the tricky case..?
That shouldn't be tricky as a user, but has been a tricky subject every
time we've been talking about implement Event Triggers in the past two
years, so I though I would include it:
create schema
Hi all,
And about proposal that originated this thread... I proposed only to add a
column on shared catalog pg_database with timestamp of its creation.
Event triggers don't cover CREATE DATABASE statement.
Regards,
--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
Blog sobre TI:
On 12/28/12 4:05 AM, Fabrízio de Royes Mello wrote:
Hi all,
And about proposal that originated this thread... I proposed only to add a
column on shared catalog pg_database with timestamp of its creation.
Event triggers don't cover CREATE DATABASE statement.
Works for me, in that case.
You'd
* Josh Berkus (j...@agliodbs.com) wrote:
This information could be extremely useful for forensics, debugging, ETL
processes (many of which create tables as part of their processes), etc.
I'd say moderately useful at best. Quite a number of things could
make the creation dates misleading or
Hi,
Tom Lane t...@sss.pgh.pa.us writes:
This proposal is about add a column datcreated on pg_database to store
the timestamp of the database creation.
I'm inclined to think that anyone who really needs this should be
pointed at event triggers. That feature (if it gets in) will allow
people
On Thu, Dec 27, 2012 at 2:13 AM, Tom Lane t...@sss.pgh.pa.us wrote:
This has been debated, and rejected, before.
I know this discussion...
To mention just one problem, are we going to add nonstandard,
non-backwards-compatible syntax to every single kind of CREATE to allow
pg_dump to
On Thu, Dec 27, 2012 at 2:04 PM, Dimitri Fontaine dimi...@2ndquadrant.fr
wrote:
Tom Lane t...@sss.pgh.pa.us writes:
This proposal is about add a column datcreated on pg_database to
store
the timestamp of the database creation.
I'm inclined to think that anyone who really needs this
Dimitri,
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
Here's a complete test case that works with my current branch, with a
tricky test while at it, of course:
Apparently I've managed to miss the tricky case..?
Sure, dropping tables, schemas, etc, would have an impact on the values.
Hi all,
This proposal is about add a column datcreated on pg_database to store
the timestamp of the database creation.
A couple weeks ago I had a trouble with a PostgreSQL instance, actually our
ERP had some strange behaviors with some data loss, but I searched for
ERRORs in log files (OS and
On 12/26/12 4:48 PM, Fabrízio de Royes Mello wrote:
Hi all,
This proposal is about add a column datcreated on pg_database to store
the timestamp of the database creation.
I agree that it would be useful. However, if we're going to get into
created dates, we should at least consider adding
* Josh Berkus (j...@agliodbs.com) wrote:
On 12/26/12 4:48 PM, Fabrízio de Royes Mello wrote:
This proposal is about add a column datcreated on pg_database to store
the timestamp of the database creation.
I agree that it would be useful. However, if we're going to get
into created dates, we
Stephen Frost sfr...@snowman.net writes:
* Josh Berkus (j...@agliodbs.com) wrote:
On 12/26/12 4:48 PM, Fabrízio de Royes Mello wrote:
This proposal is about add a column datcreated on pg_database to store
the timestamp of the database creation.
I agree that it would be useful. However, if
* Tom Lane (t...@sss.pgh.pa.us) wrote:
To mention just one problem, are we going to add nonstandard,
non-backwards-compatible syntax to every single kind of CREATE to allow
pg_dump to preserve the creation dates?
Perhaps 'ALTER' would be a better place to put it, but concerns around
how to
This information could be extremely useful for forensics, debugging, ETL
processes (many of which create tables as part of their processes), etc.
I'd say moderately useful at best. Quite a number of things could
make the creation dates misleading or not distinctive (think partition
42 matches
Mail list logo
