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
On 2013-01-03 11:03:17 +0100, Hannu Krosing wrote:
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
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
On Mon, 2012-12-31 at 17:44 -0300, Alvaro Herrera wrote:
Alvaro Herrera wrote:
Guillaume Lelarge wrote:
On Mon, 2012-12-31 at 11:03 -0300, Alvaro Herrera wrote:
I think this (have a config option, and have SIGHUP work as expected)
would be useful to demo in worker_spi, if you care
Hi hackers.
Is it by design that you can't setval(seq, value) a sequence to a value
which returns the first value:
See the sample below for better explanation:
hannu=# create sequence s;
CREATE SEQUENCE
hannu=# select nextval('s');
nextval
-
1
(1 row)
hannu=# select
Hello
postgres=# select setval('xx', 1, false);
setval
1
(1 row)
postgres=# select nextval('xx');
nextval
-
1
(1 row)
Regards
Pavel
2013/1/3 Hannu Krosing ha...@2ndquadrant.com:
Hi hackers.
Is it by design that you can't setval(seq, value) a sequence to a
On 01/03/2013 11:18 AM, Andres Freund wrote:
On 2013-01-03 11:03:17 +0100, Hannu Krosing wrote:
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
2013-01-02 11:54 keltezéssel, Boszormenyi Zoltan írta:
2013-01-02 10:37 keltezéssel, Boszormenyi Zoltan írta:
2013-01-02 10:12 keltezéssel, Magnus Hagander írta:
On Wed, Jan 2, 2013 at 9:59 AM, Boszormenyi Zoltan z...@cybertec.at
mailto:z...@cybertec.at wrote:
2013-01-02 01:24
* 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
* Hannu Krosing (ha...@krosing.net) wrote:
Can't we actually fix these to preserve file creation date like tar
does and still keep
unix file semantics ?
I'm not sure that I really see the advantage to trying to use the
filesystem to keep this information for us..?
So it is as about agreeing
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
On 01/03/2013 02:17 PM, Stephen Frost wrote:
* Hannu Krosing (ha...@krosing.net) wrote:
Can't we actually fix these to preserve file creation date like tar
does and still keep
unix file semantics ?
I'm not sure that I really see the advantage to trying to use the
filesystem to keep this
* 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
* Hannu Krosing (ha...@krosing.net) wrote:
But then some customer comes and wants it to mean when was this
replica database created ?
That's an entirely different question, imv, than what we're talking
about.
I'm not saying that it won't be asked, but as it's a different question,
we can look
On 01/03/2013 02:42 PM, Stephen Frost wrote:
* Hannu Krosing (ha...@krosing.net) wrote:
But then some customer comes and wants it to mean when was this
replica database created ?
That's an entirely different question, imv, than what we're talking
about.
I'm not saying that it won't be asked,
On Sat, Dec 3, 2011 at 4:46 PM, Peter Eisentraut peter_e(at)gmx(dot)net wrote:
I noticed the following object types don't have support for an ALTER ...
RENAME command:
DOMAIN (but ALTER TYPE works)
FOREIGN DATA WRAPPER
OPERATOR
RULE
SERVER
Are there any restrictions why these couldn't be
On Thu, Jan 3, 2013 at 8:46 AM, Hannu Krosing ha...@2ndquadrant.com wrote:
How is what does database creation date mean? a different question ?
It is same question as :
what is the creation date of db when I create a replica of my database from
backup?
does it depend on how I restore my
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
On Tue, Jan 1, 2013 at 10:10 AM, Magnus Hagander mag...@hagander.net wrote:
So, it turns out the reason I got no feedback on this tool, was that I
forgot both to email about and to actually push the code to github :O
So this is actually code that's almost half a year old and that I was
On 1/3/13 6:34 AM, Hannu Krosing 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 too many things change those. Moving to a
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 1/1/13 6:48 PM, Tom Lane wrote:
I wrote:
I'm inclined to think that Heikki's patch doesn't go far enough, if we
want to optimize behavior in this case. What we really want to happen
is that parsing, planning, and execution all happen in the caller's
memory context, with no copying of
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.
Peter Eisentraut pete...@gmx.net writes:
On 1/1/13 6:48 PM, Tom Lane wrote:
Here's a draft patch for that.
This didn't make a difference in my test case. I might have to do some
bisecting to find where the problem was introduced.
Could we see the test case? Or at least oprofile results for
On 01/03/2013 03:09 PM, Robert Haas wrote:
On Thu, Jan 3, 2013 at 8:46 AM, Hannu Krosing ha...@2ndquadrant.com wrote:
How is what does database creation date mean? a different question ?
It is same question as :
what is the creation date of db when I create a replica of my database from
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 3:13 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jan 1, 2013 at 10:10 AM, Magnus Hagander mag...@hagander.net wrote:
So, it turns out the reason I got no feedback on this tool, was that I
forgot both to email about and to actually push the code to github :O
So
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
Hello,
I'm trying to print out the tuples in the b-tree nodes for analysis, but
when iterate over more than the first entry of the tuples (scanKey++), I
strangely get the error below on query execution:
ERROR: relation simpletest does not exist
LINE 1: SELECT * FROM simpletest WHERE id = 50;
On Thu, Jan 3, 2013 at 11:15 AM, Hannu Krosing ha...@2ndquadrant.com wrote:
This is what I did with my sample pl/python function ;)
Yeah, except that the c in ctime does not stand for create, and
therefore the function isn't necessarily reliable. The problem is
even worse for tables, where a
Date: Sat, 29 Dec 2012 23:45:06 -0500
Subject: Re: [HACKERS] Writing Trigger Functions in C
From: robertmh...@gmail.com
To: charle...@outlook.com
CC: cbbro...@gmail.com; pgsql-hackers@postgresql.org
On Mon, Dec 24, 2012 at 10:43 AM, Charles Gomes
On Thu, Jan 3, 2013 at 11:32 AM, Magnus Hagander mag...@hagander.net wrote:
Any particular reason? It goes pretty tightly together with
pg_receivexlog, which is why I'd prefer putting it alongside that one.
But if you have a good argument against it, I can change my mind :)
Mostly that it
On 03.01.2013 01:15, Tomas Vondra wrote:
2) a new global/stat directory
--
The pgstat.stat file was originally saved into the global directory,
but with so many files that would get rather messy so I've created a new
global/stat directory and all the files are stored
I've been getting complaints lately about failures of parallel builds
of the Fedora Postgres RPMs on the same machine. I just figured out
what's going on: the pg_upgrade regression test script starts test
postmasters using the default value of listen_addresses, which means
that they try to bind
On Thu, Jan 3, 2013 at 12:27 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jan 3, 2013 at 11:15 AM, Hannu Krosing ha...@2ndquadrant.com wrote:
This is what I did with my sample pl/python function ;)
Yeah, except that the c in ctime does not stand for create, and
therefore the function
Robert,
In my view, the biggest problem with recovery.conf is that the
parameters in there are not GUCs, which means that all of the
infrastructure that we've built for managing GUCs does not work with
them. As an example, when we converted recovery.conf to use the same
lexer that the GUC
On 01/03/2013 12:58 PM, Tom Lane wrote:
I've been getting complaints lately about failures of parallel builds
of the Fedora Postgres RPMs on the same machine. I just figured out
what's going on: the pg_upgrade regression test script starts test
postmasters using the default value of
On 3.1.2013 18:47, Heikki Linnakangas wrote:
On 03.01.2013 01:15, Tomas Vondra wrote:
2) a new global/stat directory
--
The pgstat.stat file was originally saved into the global directory,
but with so many files that would get rather messy so I've created a new
On Thu, Jan 3, 2013 at 8:31 PM, Tomas Vondra t...@fuzzy.cz wrote:
On 3.1.2013 18:47, Heikki Linnakangas wrote:
On 03.01.2013 01:15, Tomas Vondra wrote:
2) a new global/stat directory
--
The pgstat.stat file was originally saved into the global directory,
but with
On 3 January 2013 18:35, Josh Berkus j...@agliodbs.com wrote:
Robert,
In my view, the biggest problem with recovery.conf is that the
parameters in there are not GUCs, which means that all of the
infrastructure that we've built for managing GUCs does not work with
them. As an example, when
KaiGai,
* Kohei KaiGai (kai...@kaigai.gr.jp) wrote:
IMO, only parser should accept command types except for ALL but
raise an error something like it is not supported yet to protect from
syntax conflicts.
Right, I agree with this.
Right now, I plan to submit a revised patch with the syntax
On Thu, Jan 3, 2013 at 12:54 PM, Christopher Browne cbbro...@gmail.com wrote:
Yep, and I think that the behaviour of tar pretty nicely characterizes
what's troublesome here. It is quite likely that a tar run will *capture*
the creation time of a file, but if you pull data from a tar archive,
Hackers,
As a reminder, we are going to close the call for presentations for
pgCon on January 15th this year, in an effort to get speakers notified
sooner. Please submit your talks as soon as you can.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers
On 1/3/13 1:02 PM, Josh Berkus wrote:
Hackers,
As a reminder, we are going to close the call for presentations for
pgCon on January 15th this year, in an effort to get speakers notified
sooner. Please submit your talks as soon as you can.
Correction, the 19th.
Also, a URL would help:
Robert Haas wrote:
Christopher Browne cbbro...@gmail.com wrote:
these timestamps Should Not be captured or carried forward by
pg_dump.
If we put a creation time into pg_database or pg_class, then
streaming replication will, as a physical replication
mechanism, carry the timestamp forward
On 01/03/2013 04:51 PM, Kevin Grittner wrote:
Robert Haas wrote:
Christopher Browne cbbro...@gmail.com wrote:
these timestamps Should Not be captured or carried forward by
pg_dump.
If we put a creation time into pg_database or pg_class, then
streaming replication will, as a physical
Andrew Dunstan wrote:
I don't especially have a horse in the race, but ISTM that if you want
the information you want it to be able to persist across dump/restore,
at least optionally. If you can happily lose it when you're forced to
recover using a logical dump then it's not that
On 01/03/2013 02:30 PM, Kevin Grittner wrote:
Andrew Dunstan wrote:
I don't especially have a horse in the race, but ISTM that if you want
the information you want it to be able to persist across dump/restore,
at least optionally. If you can happily lose it when you're forced to
recover
Andrew Dunstan and...@dunslane.net writes:
On 01/03/2013 12:58 PM, Tom Lane wrote:
Does anyone have an objection to fixing the pg_upgrade test script
to suppress the TCP socket?
Should be OK. We can't do that on Windows, though, so please make it
conditional so we don't break Mingw
Folks,
The PGCon Call for Papers went out last month. But you have about two weeks
left to respond. If you are doing something interesting with PostgreSQL,
please submit
a proposal. You might be one of the backend hackers or work on a
PostgreSQL related project and want to share your know-how
The ./src/bin/pg_dump README contains several inoperable examples.
First, this suggestion:
| or to list tables:
|
| pg_restore backup-file --table | less
seems bogus, i.e. the --table option requires an argument specifing
which table to restore, and does not list tables. Next, this
59 matches
Mail list logo
