2013-12-17 Emre Hasegeli e...@hasegeli.com:
Query planner never chooses to use the index for the operators which
the index is particularly useful because selectivity estimation functions
are missing. I am planning to work on them.
Attached patch adds selectivity estimation functions for the
On Sat, Jan 4, 2014 at 1:33 AM, Gabriele Bartolini
gabriele.bartol...@2ndquadrant.it wrote:
Hello,
please find attached the patch that adds basic support for the
pg_stat_archiver system view, which allows users that have continuous
archiving procedures in place to keep track of some
Hi Magnus,
Il 04/01/14 13:25, Magnus Hagander ha scritto:
My first reaction was that exactly those two things were missing. And
then I read your whole email :)
:)
With those two, I think it would make much sense to have a view like
this.
Ok, I will prepare version 2 with those.
I'd
On Tue, Dec 17, 2013 at 08:58:13PM +0200, Emre Hasegeli wrote:
Hi,
Attached patch adds GiST support to the inet datatypes with two new
operators. Overlaps operator can be used with exclusion constraints.
Is adjacent to operator is just the negator of it. Index uses only
the network bits of
Szymon Guz mabew...@gmail.com wrote:
is clang supported for compiling Postgres? I found some websites
with information that some people compiled Postgres succesfully,
but I got plenty of errors even with running ./configure. So I'm
wondering if it's my fault, however gcc works properly.
I am
On 19 November 2013 22:54, Kevin Grittner kgri...@ymail.com wrote:
Szymon Guz mabew...@gmail.com wrote:
is clang supported for compiling Postgres? I found some websites
with information that some people compiled Postgres succesfully,
but I got plenty of errors even with running
On 19 November 2013 23:02, Szymon Guz mabew...@gmail.com wrote:
On 19 November 2013 22:54, Kevin Grittner kgri...@ymail.com wrote:
Szymon Guz mabew...@gmail.com wrote:
is clang supported for compiling Postgres? I found some websites
with information that some people compiled Postgres
On Thu, Nov 14, 2013 at 12:28 AM, Tom Lane t...@sss.pgh.pa.us wrote:
2) Allow foreign tables to have CHECK constraints
Like NOT NULL, I think we don't need to enforce the check duroing
INSERT/UPDATE against foreign table.
Really? It's one thing to say that somebody who adds a CHECK
Robert Haas robertmh...@gmail.com writes:
On Thu, Nov 14, 2013 at 12:28 AM, Tom Lane t...@sss.pgh.pa.us wrote:
2) Allow foreign tables to have CHECK constraints
Like NOT NULL, I think we don't need to enforce the check duroing
INSERT/UPDATE against foreign table.
Really?
I think it's been
Shigeru Hanada shigeru.han...@gmail.com writes:
I'd like to propose adding inheritance support for foriegn tables.
David Fetter mentioned this feature last July, but it seems stalled.
http://www.postgresql.org/message-id/20130719005601.ga5...@fetter.org
The discussion there pointed out that
Hi everyone,
I will try answer on all questions related to proposed National
Characters support.
2)Provide support for the new GUC nchar_collation to provide the
database with information about the default collation that needs to
be
used for the new data types.
A GUC seems like completely
Boguk, Maksym escribió:
I think I give a wrong description there... it will be not GUC but
GUC-type value which will be initialized during CREATE DATABASE and will
be read only after, very similar to the lc_collate.
So I think name national_lc_collate will be better.
Function of this value
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Also, as far as I understand what we want to control here is the
encoding that the strings are in (the mapping of bytes to characters),
not the collation (the way a set of strings are ordered). So it doesn't
make sense to set the NATIONAL
From: Alvaro Herrera [mailto:alvhe...@2ndquadrant.com]
Boguk, Maksym escribió:
I think I give a wrong description there... it will be not GUC but
GUC-type value which will be initialized during CREATE DATABASE and
will be read only after, very similar to the lc_collate.
So I think
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Also, as far as I understand what we want to control here is the
encoding that the strings are in (the mapping of bytes to
characters),
not the collation (the way a set of strings are ordered). So
-Original Message-
From: Tatsuo Ishii [mailto:is...@postgresql.org]
Also I don't understand why you need UTF-16 support as a database
encoding
because UTF-8 and UTF-16 are logically equivalent, they are just
different
represention (encoding) of Unicode. That means if we already
Arulappan, Arul Shaji a...@fast.au.fujitsu.com writes:
Given below is a design draft for this functionality:
Core new functionality (new code):
1)Create and register independent NCHAR/NVARCHAR/NTEXT data types.
2)Provide support for the new GUC nchar_collation to provide the
database with
On Mon, Jul 15, 2013 at 05:11:40PM +0900, Tatsuo Ishii wrote:
Does support for alternative multi-byte encodings have something to do
with the Han unification controversy? I don't know terribly much about
this, so apologies if that's just wrong.
There's a famous problem regarding
On Mon, Jul 15, 2013 at 4:37 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jul 5, 2013 at 2:35 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
Yes, what I know almost all use utf8 without problems. Long time I didn't
see any request for multi encoding support.
Well, not *everything*
On Mon, Jul 15, 2013 at 4:37 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jul 5, 2013 at 2:35 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Yes, what I know almost all use utf8 without problems. Long time I didn't
see any request for multi encoding support.
Well, not
On Fri, Jul 5, 2013 at 2:35 PM, Pavel Stehule
pavel.steh...@gmail.com wrote:
Yes, what I know almost all use utf8 without problems. Long time I
didn't see any request for multi encoding support.
Well, not *everything* can be represented as UTF-8; I think this is
particularly an issue
On Mon, Jul 15, 2013 at 8:58 AM, Tatsuo Ishii is...@postgresql.org wrote:
Also I don't understand why you need UTF-16 support as a database
encoding because UTF-8 and UTF-16 are logically equivalent, they are
just different represention (encoding) of Unicode. That means if we
already support
On 7/15/13 1:26 AM, Arulappan, Arul Shaji wrote:
Yes, the idea is that users will be able to declare columns of type
NCHAR or NVARCHAR which will use the pre-determined encoding type. If we
say that NCHAR is UTF-8 then the NCHAR column will be of UTF-8 encoding
irrespective of the database
On Fri, Jul 5, 2013 at 2:35 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
Yes, what I know almost all use utf8 without problems. Long time I didn't
see any request for multi encoding support.
Well, not *everything* can be represented as UTF-8; I think this is
particularly an issue with Asian
On Fri, Jul 5, 2013 at 2:35 PM, Pavel Stehule
pavel.steh...@gmail.com wrote:
Yes, what I know almost all use utf8 without problems. Long time I
didn't see any request for multi encoding support.
Well, not *everything* can be represented as UTF-8; I think this is
particularly an issue
Ishii san,
Thank you for your positive and early response.
-Original Message-
From: Tatsuo Ishii [mailto:is...@postgresql.org]
Sent: Friday, 5 July 2013 3:02 PM
To: Arulappan, Arul Shaji
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Proposal - Support for National
-Original Message-
From: Claudio Freire [mailto:klaussfre...@gmail.com]
Sent: Friday, 5 July 2013 3:41 PM
To: Tatsuo Ishii
Cc: Arulappan, Arul Shaji; PostgreSQL-Dev
Subject: Re: [HACKERS] Proposal - Support for National Characters
functionality
On Fri, Jul 5, 2013 at 2:02 AM
On 07/05/2013 02:12 AM, Arulappan, Arul Shaji wrote:
- Support for UTF16 column encoding and representing NCHAR and
NVARCHAR columns in UTF16 encoding in all databases.
Why do yo need UTF-16 as the database encoding? UTF-8 is already
supported,
and any UTF-16 character can be represented in
On 7/4/13 10:11 PM, Arulappan, Arul Shaji wrote:
The main aim at the moment is to get some feedback on the above to know
if this feature is something that would benefit PostgreSQL in general,
and if users maintaining DBs in non-English speaking regions will find
this beneficial.
For European
Yes, what I know almost all use utf8 without problems. Long time I didn't
see any request for multi encoding support.
Dne 5.7.2013 20:28 Peter Eisentraut pete...@gmx.net napsal(a):
On 7/4/13 10:11 PM, Arulappan, Arul Shaji wrote:
The main aim at the moment is to get some feedback on the above
Arul Shaji,
NCHAR support is on our TODO list for some time and I would like to
welcome efforts trying to implement it. However I have a few
questions:
This is a proposal to implement functionalities for the handling of
National Characters.
[Introduction]
The aim of this proposal is to
On Fri, Jul 5, 2013 at 2:02 AM, Tatsuo Ishii is...@postgresql.org wrote:
- Support for NATIONAL_CHARACTER_SET GUC variable that will determine
the encoding that will be used in NCHAR/NVARCHAR columns.
You said NCHAR's encoding is UTF-8. Why do you need the GUC if NCHAR's
encoding is fixed to
On 13.05.2013 15:39, Mark Salter wrote:
I used the following patch to add lock support aarch64. It is just a
copy of the arm support based on gcc builtins. Postgresql built with
this patch passes the various tests.
I think this needs an #ifdef HAVE_GCC_INT_ATOMICS, like the ARM codepath.
If
On Mon, 2013-05-13 at 16:15 +0300, Heikki Linnakangas wrote:
On 13.05.2013 15:39, Mark Salter wrote:
I used the following patch to add lock support aarch64. It is just a
copy of the arm support based on gcc builtins. Postgresql built with
this patch passes the various tests.
I think this
On Mon, May 13, 2013 at 8:15 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 13.05.2013 15:39, Mark Salter wrote:
I used the following patch to add lock support aarch64. It is just a
copy of the arm support based on gcc builtins. Postgresql built with
this patch passes the various
Mark Salter msal...@redhat.com writes:
I used the following patch to add lock support aarch64. It is just a
copy of the arm support based on gcc builtins. Postgresql built with
this patch passes the various tests.
Couldn't we just do
-#if defined(__arm__) || defined(__arm)
+#if
On 13.05.2013 17:26, Merlin Moncure wrote:
I'm starting to wonder why we don't always use gcc atomics if they are
available and assembly implementation is not (any maybe, even if it
is).
That was discussed a while ago, but there were a lot of claims that
__sync_lock_test_and_set is broken on
On 13.05.2013 18:14, Tom Lane wrote:
Mark Saltermsal...@redhat.com writes:
I used the following patch to add lock support aarch64. It is just a
copy of the arm support based on gcc builtins. Postgresql built with
this patch passes the various tests.
Couldn't we just do
-#if defined(__arm__)
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 13.05.2013 18:14, Tom Lane wrote:
Couldn't we just do
-#if defined(__arm__) || defined(__arm)
+#if defined(__arm__) || defined(__arm) || defined(__aarch64__)
That would imply falling back to swpb instruction also on aarch64, which
won't
Darren Duncan wrote:
Consider the context however. We're talking about a UNIQUE constraint and so
what we want to do is prevent the existence of multiple tuples in a relation
that are the same for some defined subset of their attributes. I would argue
that logically, and commonsensically,
Darren Duncan wrote:
The standard defines UNIQUE on the basis of the UNIQUE predicate:
unique predicate ::= UNIQUE table subquery
and states:
1) Let T be the result of the table subquery.
2) If there are no two rows in T such that the value of each column
in one row is non-null and is not
On 2013.03.26 1:40 AM, Albe Laurenz wrote:
Darren Duncan wrote:
So, determining if 2 rows are the same involves an iteration of dyadic logical
AND over the predicates for each column comparison. Now logical AND has an
identity value, which is TRUE, because TRUE AND p (and p AND TRUE) results
On 27/03/13 06:14, Darren Duncan wrote:
On 2013.03.26 1:40 AM, Albe Laurenz wrote:
Darren Duncan wrote:
So, determining if 2 rows are the same involves an iteration of
dyadic logical
AND over the predicates for each column comparison. Now logical AND
has an
identity value, which is TRUE,
Darren Duncan wrote:
From my usage and
http://www.postgresql.org/docs/9.2/interactive/sql-createtable.html I see that
Postgres requires constraints like unique (and primary) keys, and foreign
keys,
to range over at least 1 attribute/column.
I propose that this be generalized so that
Albe Laurenz laurenz.a...@wien.gv.at writes:
Darren Duncan wrote:
I propose that this be generalized so that constraints may instead be
nullary,
that is, range over zero or more attributes/columns instead.
Since an imagined zero-column query would have an empty set of
result columns, you
On 2013.03.25 1:17 AM, Albe Laurenz wrote:
Darren Duncan wrote:
From my usage and
http://www.postgresql.org/docs/9.2/interactive/sql-createtable.html I see that
Postgres requires constraints like unique (and primary) keys, and foreign keys,
to range over at least 1 attribute/column.
I
On 26 March 2013 05:04, Darren Duncan dar...@darrenduncan.net wrote:
On 2013.03.25 1:17 AM, Albe Laurenz wrote:
The desired effect can be had today with a unique index:
CREATE TABLE singleton (id integer);
CREATE UNIQUE INDEX singleton_idx ON singleton((1));
Okay, that is helpful, and less
Brendan Jurd dire...@gmail.com writes:
On 26 March 2013 05:04, Darren Duncan dar...@darrenduncan.net wrote:
On 2013.03.25 1:17 AM, Albe Laurenz wrote:
The desired effect can be had today with a unique index:
CREATE TABLE singleton (id integer);
CREATE UNIQUE INDEX singleton_idx ON
On Wed, Oct 24, 2012 at 12:06:35PM -0400, Tom Lane wrote:
Noah Misch n...@leadboat.com writes:
For FKs, we currently document that The referenced columns must be the
columns of a non-deferrable unique or primary key constraint in the
referenced
table. Taking that literally, one might
On Wed, Oct 24, 2012 at 12:36:31AM -0400, Tom Lane wrote:
The proposed patch uses this if the referencing column is an array:
SELECT 1 WHERE
(SELECT pg_catalog.count(DISTINCT y) FROM pg_catalog.unnest($1) y)
OPERATOR(pg_catalog.=)
(SELECT pg_catalog.count(*) FROM
(SELECT 1 FROM
Noah Misch n...@leadboat.com writes:
For FKs, we currently document that The referenced columns must be the
columns of a non-deferrable unique or primary key constraint in the referenced
table. Taking that literally, one might imagine that bare UNIQUE indexes do
not qualify. However,
Marco Nenciarini marco.nenciar...@2ndquadrant.it writes:
Please find the attached refreshed patch (v2) which fixes the loose ends
you found.
Attached is a v3 patch that updates the syntax per discussion, uses what
seems to me to be a saner (more extensible) catalog representation, and
contains
On 10/22/12 4:22 PM, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
Well, I think if that's the best we can do, you original proposal of
ditching the column constraint syntax altogether might be for the
best. I wasn't too excited about that before, but I think having two
different
Now that it seems like we've got consensus on syntax, let's talk about
some implementation issues.
Ordinarily, the query executed during an insert or update on the
referencing table looks like, for example,
SELECT 1 FROM ONLY public.pk x
WHERE f1 OPERATOR(pg_catalog.=) $1 FOR SHARE OF x
where
2012/10/22 Tom Lane t...@sss.pgh.pa.us:
I wrote:
I tested, and indeed this seems to work:
CREATE TABLE t1 (c int[] WHERE EACH ELEMENT REFERENCES t2);
and it's perfectly sensible from an English-grammar standpoint too.
If we take that, how would we spell the table-constraint case
On 10/22/2012 12:08 PM, Tom Lane wrote:
I wrote:
I tested, and indeed this seems to work:
CREATE TABLE t1 (c int[] WHERE EACH ELEMENT REFERENCES t2);
and it's perfectly sensible from an English-grammar standpoint too.
If we take that, how would we spell the table-constraint case
On Monday, October 22, 2012 06:08:32 PM Tom Lane wrote:
I wrote:
I tested, and indeed this seems to work:
CREATE TABLE t1 (c int[] WHERE EACH ELEMENT REFERENCES t2);
and it's perfectly sensible from an English-grammar standpoint too.
If we take that, how would we spell the
On 10/22/2012 12:13 PM, Andres Freund wrote:
On Monday, October 22, 2012 06:08:32 PM Tom Lane wrote:
I wrote:
I tested, and indeed this seems to work:
CREATE TABLE t1 (c int[] WHERE EACH ELEMENT REFERENCES t2);
and it's perfectly sensible from an English-grammar standpoint too.
If we
Robert Haas robertmh...@gmail.com writes:
On Mon, Oct 22, 2012 at 12:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
I tested, and indeed this seems to work:
CREATE TABLE t1 (c int[] WHERE EACH ELEMENT REFERENCES t2);
and it's perfectly sensible from an English-grammar standpoint too.
If
On Mon, Oct 22, 2012 at 12:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
I tested, and indeed this seems to work:
CREATE TABLE t1 (c int[] WHERE EACH ELEMENT REFERENCES t2);
and it's perfectly sensible from an English-grammar standpoint too.
If we take that, how would we spell the
On Mon, Oct 22, 2012 at 2:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm not thrilled with the inconsistency either, but given the
constraints we're under, it seems like the best we can do. (I feel,
as Andrew does, that shoving WHERE into the table-constraint syntax
would not be an
Robert Haas robertmh...@gmail.com writes:
Well, I think if that's the best we can do, you original proposal of
ditching the column constraint syntax altogether might be for the
best. I wasn't too excited about that before, but I think having two
different syntaxes is going to be even worse.
On 10/18/2012 10:26 PM, Tom Lane wrote:
Another possibility is to forget about the column constraint ELEMENT
REFERENCES syntax, and only support the table-constraint syntax with
ELEMENT inside the column list --- I've not checked, but I think that
syntax doesn't have any ambiguity problems.
Andrew Dunstan and...@dunslane.net writes:
I'm late to this party, so I apologize in advance if this has already
been considered, but do we actually need a special syntax? Can't we just
infer that we have one of these when the referring column is an array
and the referenced column is of the
On 10/19/2012 03:55 PM, Tom Lane wrote:
This thought also crystallizes something else that had been bothering me,
which is that ELEMENT alone is a pretty bad choice of syntax because
it entirely fails to make clear which of these semantics is meant.
I'm tempted to propose that we use
On Fri, Oct 19, 2012 at 3:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
That doesn't get us any closer to having a working column-constraint
syntax unfortunately, because EACH is not a reserved word either
so EACH ELEMENT REFERENCES still isn't gonna work. I'm getting
more willing to give up on
Andrew Dunstan and...@dunslane.net writes:
On 10/19/2012 03:55 PM, Tom Lane wrote:
That doesn't get us any closer to having a working column-constraint
syntax unfortunately, because EACH is not a reserved word either
so EACH ELEMENT REFERENCES still isn't gonna work. I'm getting
more willing
Robert Haas robertmh...@gmail.com writes:
This is a little sneaky, but I presume you only get the grammar
conflict if you try to sneak the each or element or each element
or whatever-you-call-it designator in BEFORE the column name. So what
about just putting it afterwards? Something like
On Fri, Oct 19, 2012 at 5:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
It looks like we could support
CREATE TABLE t1 (c int[] REFERENCES BY ELEMENT t2);
but (1) this doesn't seem terribly intelligible to me, and
(2) I don't see how we modify that if we want to provide
Claudio Freire klaussfre...@gmail.com writes:
What about something more generic?
CREATE TABLE tname ( cname type [(expr)] REFERENCES t2name
[(t2expr)] )
Meaning, if expr is missing, it's taken expr = cname, if not,
it's the result of that expression the one that references the target
Andres Freund and...@2ndquadrant.com writes:
What about sticking a WHERE in there? I.e. FOREIGN KEY (foo, WHERE EACH
ELEMENT OF bar) ...
Well, we don't really need it in the table-constraint case. The
column-constraint case is the sticking point.
I tested, and indeed this seems to work:
On 10/19/2012 04:40 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 10/19/2012 03:55 PM, Tom Lane wrote:
That doesn't get us any closer to having a working column-constraint
syntax unfortunately, because EACH is not a reserved word either
so EACH ELEMENT REFERENCES still
Marco Nenciarini marco.nenciar...@2ndquadrant.it writes:
Please find the attached refreshed patch (v2) which fixes the loose ends
you found.
I've started looking at this patch, and the first thing I notice is that
the syntax doesn't work. It's ambiguous, and this:
%left JOIN CROSS
I wrote:
Or we could go back to using ARRAY here --- that should be safe since
ARRAY is already fully reserved.
Ugh ... no, that doesn't work, because ARRAY[...] is allowed in c_expr
and hence b_expr. So the ambiguity would still be there. We'd need a
different fully-reserved keyword to go
On Tue, Sep 18, 2012 at 05:52:51PM +0200, Marco Nenciarini wrote:
please find attached the refreshed v1 patch.
I perused this version in comparison to the last version I reviewed, finding
minor problems. First, a warning:
tablecmds.c: In function `ATExecAddConstraint':
tablecmds.c:5898:
Hi,
please find attached the refreshed v1 patch.
Regards,
Marco
--
Marco Nenciarini - 2ndQuadrant Italy
PostgreSQL Training, Services and Support
marco.nenciar...@2ndquadrant.it | www.2ndQuadrant.it
Array-ELEMENT-foreign-key-v1-refreshed.patch.bz2
Description: application/bzip
--
Sent
On 8/27/12 12:40 PM, Robert Haas wrote:
On Sat, Aug 25, 2012 at 1:30 PM, David Johnstonpol...@yahoo.com wrote:
My internals knowledge is basically zero but it would seem that If you
simply wanted the end-of-transaction result you could just record nothing
during the transaction and then copy
On Sat, Aug 25, 2012 at 1:30 PM, David Johnston pol...@yahoo.com wrote:
My internals knowledge is basically zero but it would seem that If you
simply wanted the end-of-transaction result you could just record nothing
during the transaction and then copy whatever values are present at commit
to
Well, the point is that I think many people have requirements that are
(1) different from each other and (2) more complicated than the
simplest case we can come up with. Some people will want to log the
application user (or some other piece of extra data); others won't.
Some people will
On Mon, Aug 27, 2012 at 1:50 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
I can't agree - why we need a some simple solution based on tools,
that are available now? I don't think we have to be hurry in support
own proprietary solutions - when isn't difficult do it just with
available tools
On Mon, Aug 20, 2012 at 7:17 PM, David Johnston pol...@yahoo.com wrote:
Ideally the decision of whether to do so could be a client decision. Not
storing intra-transaction changes is easier than storing all changes.
Not really. If you don't care about suppressing intra-transaction
changes, you
-Original Message-
From: Robert Haas [mailto:robertmh...@gmail.com]
Sent: Saturday, August 25, 2012 12:46 PM
To: David Johnston
Cc: Jeff Davis; Vlad Arkhipov; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] temporal support patch
On Mon, Aug 20, 2012 at 7:17 PM, David Johnston
Jeff Davis pg...@j-davis.com wrote:
On Tue, 2012-08-21 at 17:07 -0500, Kevin Grittner wrote:
The fact that it has an unknown sequence number or timestamp for
purposes of ordering visibility of transactions doesn't mean you
can't show that it completed in an audit log. In other words, I
On Tue, 2012-08-21 at 17:07 -0500, Kevin Grittner wrote:
The fact that it has an unknown sequence number or timestamp for
purposes of ordering visibility of transactions doesn't mean you
can't show that it completed in an audit log. In other words, I
think the needs for a temporal database
On 08/21/2012 01:52 PM, Jeff Davis wrote:
On Mon, 2012-08-20 at 16:32 -0700, Josh Berkus wrote:
Personally, I would prefer a tool which just made it simpler to build my
own triggers, and made it automatic for the history table to track
changes in the live table. I think anything we build which
I have written one approach to audit tables, available from
https://github.com/akaariai/pgsql_shadow_tables
The approach is that every table is backed by a similar audit table +
some meta information. The tables and triggers to update the audit
tables are managed by plpgsql procedures.
Jeff Davis pg...@j-davis.com wrote:
On Mon, 2012-08-20 at 19:32 -0500, Kevin Grittner wrote:
Josh Berkus j...@agliodbs.com wrote:
This is sounding like a completely runaway spec on what should
be a simple feature.
I hate to contribute to scope creep (or in this case scope
screaming
On Mon, Aug 20, 2012 at 09:33:45PM -0700, Jeff Davis wrote:
On Mon, 2012-08-20 at 19:17 -0400, David Johnston wrote:
Ideally the decision of whether to do so could be a client
decision. Not storing intra-transaction changes is easier than
storing all changes. At worse you could stage up
On 22/08/12 02:16, Kevin Grittner wrote:
Jeff Davis pg...@j-davis.com wrote:
On Mon, 2012-08-20 at 19:32 -0500, Kevin Grittner wrote:
Josh Berkus j...@agliodbs.com wrote:
This is sounding like a completely runaway spec on what should
be a simple feature.
I hate to contribute to scope
Excerpts from Gavin Flower's message of mar ago 21 16:51:57 -0400 2012:
On 22/08/12 02:16, Kevin Grittner wrote:
So, if you want to allow serializable temporal queries, the timing
of a read-write serializable transaction can't be locked down until
all overlapping read-write serializable
Gavin Flower gavinflo...@archidevsys.co.nz wrote:
So if I understand correctly...
If there is a very long running transaction, say 1 hour, then all
(or just some? - depending) transactions that nominally start and
finish within that time, can not have definitive start times until
the very
Alvaro Herrera alvhe...@2ndquadrant.com wrote:
I think there would need to be a way to also list transactions
which are in progress -- this would include not only live
transactions, but also all those transactions that have actually
committed but are not yet listed as committed because their
On Sun, Aug 19, 2012 at 6:28 PM, Jeff Davis pg...@j-davis.com wrote:
The other issue is how to handle multiple changes of the same record
within the transaction. Should they be stored or not?
In a typical audit log, I don't see any reason to. The internals of a
transaction should be
-Original Message-
From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
ow...@postgresql.org] On Behalf Of Robert Haas
Sent: Monday, August 20, 2012 5:04 PM
To: Jeff Davis
Cc: Vlad Arkhipov; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] temporal support patch
On 8/20/12 4:17 PM, David Johnston wrote:
The issue with adding the PostgreSQL role to the database in this way is
that you now can never delete that role or reassign it to another entity. I
guess with temporal you could do so and basically have the identity-role
relationship define over
Josh Berkus j...@agliodbs.com wrote:
This is sounding like a completely runaway spec on what should be
a simple feature.
I hate to contribute to scope creep (or in this case scope screaming
down the tracks at full steam), but I've been watching this with a
queasy feeling about interaction
On Mon, 2012-08-20 at 17:04 -0400, Robert Haas wrote:
On Sun, Aug 19, 2012 at 6:28 PM, Jeff Davis pg...@j-davis.com wrote:
The other issue is how to handle multiple changes of the same record
within the transaction. Should they be stored or not?
In a typical audit log, I don't see any
On Mon, 2012-08-20 at 19:17 -0400, David Johnston wrote:
Ideally the decision of whether to do so could be a client decision. Not
storing intra-transaction changes is easier than storing all changes. At
worse you could stage up all changed then simply fail to store all
intermediate results
On Mon, 2012-08-20 at 16:32 -0700, Josh Berkus wrote:
This is sounding like a completely runaway spec on what should be a
simple feature.
My feeling as well. However, we will eventually want to coalesce around
some best practices and make it easy and robust for typical cases.
Personally, I
On Mon, 2012-08-20 at 19:32 -0500, Kevin Grittner wrote:
Josh Berkus j...@agliodbs.com wrote:
This is sounding like a completely runaway spec on what should be
a simple feature.
I hate to contribute to scope creep (or in this case scope screaming
down the tracks at full steam), but
801 - 900 of 1809 matches
Mail list logo
