Here is a test of the fast insert patch. The patch has gone through some
changes, so this set of tests is to see the current performance impact
compared with HEAD.
The test is simple: inserting a bunch of integer arrays into a table
with a GIN index on the array column.
I'm testing with small
Koichi Suzuki koichi@gmail.com writes:
It's simply because we should not refer to system catalog during the recovery.
I don't understand how this is connected to anything to do with prefetching?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about
Sorry, I attached incorrect patch file.
It is the correct one.
KaiGai Kohei wrote:
Robert,
The attached patch is a draft to replace RedHat/Fedora RPM centric
expressions, to add a reference at Database Roles and Privileges
chapter and a bit cleanups for the latest revision (r1467).
In the
On Mon, 2009-01-26 at 09:48 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
In various places in current HEAD we throw a checkpoint when we want to
be certain that all buffers have been flushed.
In recovery, a checkpoint isn't always a restartpoint for two reasons:
timing and rmgr
On Sun, 2009-01-25 at 19:56 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
2. Kill all connections by given user. Hmm, not used for anything,
actually. Should remove the roleId argument from GetConflictingVirtualXIDs.
No, because we still need to add code to kill-connected-users
On Sun, 2009-01-25 at 12:13 +, Grzegorz Jaskiewicz wrote:
On 2009-01-25, at 09:04, Simon Riggs wrote:
On Sat, 2009-01-24 at 21:58 +0200, Heikki Linnakangas wrote:
When replaying a DROP TABLE SPACE, you first try to remove the
directory, and if that fails, you assume that it's
--On 25. Januar 2009 13:36:35 -0500 Tom Lane t...@sss.pgh.pa.us wrote:
But per spec, UPDATABLE should be the default (if not now, then
eventually). Are you proposing
CREATE [OR REPLACE] [[NOT] UPDATABLE] VIEW ...
? Seems confusing.
Good point. We need a better phrasing to restore
Hi,
Simon Riggs wrote:
On Sun, 2009-01-25 at 19:56 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
2. Kill all connections by given user. Hmm, not used for anything,
actually. Should remove the roleId argument from GetConflictingVirtualXIDs.
No, because we still need to add code to
On Sun, 2009-01-25 at 12:06 -0500, Tom Lane wrote:
If we want to ensure that 8.5 development opens soon, what we have to
do is reject those two patches, revert updatable views, and finish up
the other stuff (which is all small and could likely be dealt with in
a week or two). That puts us
On Sun, 2009-01-25 at 12:06 -0500, Tom Lane wrote:
If we want to ensure that 8.5 development opens soon, what we have to
do is reject those two patches, revert updatable views, and finish up
the other stuff (which is all small and could likely be dealt with in
a week or two). That puts us in
Simon Riggs wrote:
On Sun, 2009-01-25 at 12:06 -0500, Tom Lane wrote:
Any release with big
features in it will take longer, whether you wait a year, or not.
Well, big features that land early in the release cycle don't delay the
release. Just the ones that are submitted in the last commit
There is another thing that's bothering me, though, which is that the
present approach to dumping rules isn't adequate. Consider the
following scenario:
1. You create a view that the system considers updatable, so
it creates
some automatic rules.
2. You don't want those rules, so you
On Mon, Jan 26, 2009 at 11:35 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I'm sure it depends on the user. Users that are more interested in the
features we already have in the bag like window functions and WITH-clause,
will obviously prefer to release earlier without hot
Simon Riggs wrote:
I don't think that particular example is a good one since the whole
point of the archive is that it should be off-server. If we're going to
be exact about the example then we should give a more realistic one,
like using scp. Unfortunately, there is no secure-remote-move
Zdenek Kotala wrote:
Alvaro Herrera píše v pá 23. 01. 2009 v 11:04 -0300:
Zdenek Kotala wrote:
I attached patch which add capability to have single record for all
realation kind in the reloption list. It is usefull in situation when
all parameters are same for all relation kinds.
Do you have
ITAGAKI Takahiro wrote:
Here is a patch to surpress compiler warnings in pg_locale.c and pg_regress.c.
There are following warnings if nls is enabled:
pg_locale.c: In function `pg_perm_setlocale':
pg_locale.c:161: warning: assignment discards qualifiers from pointer
target type
and if
On Sun, Jan 25, 2009 at 12:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Particularly with regard to hot standby, which by any sane reading was
not close to being committable on 1 November (a fortiori from the fact
that it's *still* not committable despite large amounts of later work).
While I
On Sun, 2009-01-25 at 12:06 -0500, Tom Lane wrote:
Particularly with regard to hot standby, which by any sane reading was
not close to being committable on 1 November (a fortiori from the fact
that it's *still* not committable despite large amounts of later
work).
I've wasted much time in
Simon has put a lot of time into Hot Standby and has followed the
pseudo-defacto community process from design through what he believes to be
near-completion; he can't be sure of completion until someone reviews his
work.
I think this is a fair critique.
Yet, albeit with almost no review
On Sun, 2009-01-25 at 16:19 +, Simon Riggs wrote:
On Fri, 2009-01-23 at 21:30 +0200, Heikki Linnakangas wrote:
Ok, then I think we have a little race condition. The startup process
doesn't get any reply indicating that the target backend has
processed
the SIGINT and set the
On Mon, 2009-01-26 at 13:35 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Sun, 2009-01-25 at 12:06 -0500, Tom Lane wrote:
Any release with big
features in it will take longer, whether you wait a year, or not.
Well, big features that land early in the release cycle don't
Simon Riggs wrote:
On Mon, 2009-01-26 at 13:35 +0200, Heikki Linnakangas wrote:
Well, big features that land early in the release cycle don't delay the
release. Just the ones that are submitted in the last commit fest.
Has that ever happened? :-)
I don't think its chance we get big
Jonah H. Harris wrote:
Looking forward, if no one
wanted to review these patches in November,
I did, and many others were active in the discussion too.
and seemingly no one wants to review them now,
I do. Thank you for your appreciation :-(.
how can we expect this to change for 8.5?
Robert Haas robertmh...@gmail.com wrote:
Still, I agree that if there's anything we should be putting our
effort into as a community right now, it's this feature. If we got
Hot Standby in the next release and everything else in the
CommitFest
got bumped, I think a lot of people would
Robert Haas wrote:
At a minimum, I think the following patches from the CommitFest wiki
should be returned with feedback or rejected:
1. SE-PostgreSQL. We handled this one badly, but there's not enough
time to fix it now. 8.5.
Unacceptable.
Please make it clear how many items should be
On Mon, 2009-01-26 at 12:05 -0300, Alvaro Herrera wrote:
Simon Riggs wrote:
On Mon, 2009-01-26 at 13:35 +0200, Heikki Linnakangas wrote:
Well, big features that land early in the release cycle don't delay the
release. Just the ones that are submitted in the last commit fest.
Simon Riggs si...@2ndquadrant.com writes:
I fail to see how rejecting unreviewed patches provides benefit for
users, developers or sponsors.
Nobody has suggested rejecting either sync replication or standby database.
The debate here is over whether to commit into 8.4 or into 8.5.
Put
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Not really, except maybe started 6 months too late. Big patches simply take a
long time to mature.
Looking back at the timeline for hot standby, it doesn't look unreasonable at
all:
September: First discussion about the
Peter Eisentraut wrote:
I don't think that particular example is a good one since the whole
point of the archive is that it should be off-server. If we're going to
be exact about the example then we should give a more realistic one,
like using scp. Unfortunately, there is no secure-remote-move
Gregory Stark st...@enterprisedb.com writes:
Put another way, the choice here is whether to have a half-baked delayed 8.4
release in 6 months or a polished on-time 8.5 release in 12 months. Either way
the feature ships and on a not terribly different timeline either.
This is pretty much
On Mon, Jan 26, 2009 at 6:48 AM, Zeugswetter Andreas OSB sIT
andreas.zeugswet...@s-itsolutions.at wrote:
Is that why other db's only make views updateable, that are created
WITH CHECK OPTION ? Should we also follow that path ?
no, the standard says that if the query expression is updatable
Andrew Dunstan wrote:
Something happened about 80 hours ago that caused my mingw buildfarm
member (gcc 3.4.2 on Win XP Pro SP2) to hang at the check stage. It
looks like it's hung in initdb.
I wonder if it could be this commit:
Log Message:
---
Make win32 builds always do
Tom Lane t...@sss.pgh.pa.us writes:
Gregory Stark st...@enterprisedb.com writes:
Put another way, the choice here is whether to have a half-baked delayed 8.4
release in 6 months or a polished on-time 8.5 release in 12 months. Either
way
the feature ships and on a not terribly different
Zdenek Kotala wrote:
Andrew Dunstan píše v pá 23. 01. 2009 v 23:57 -0500:
Zdenek Kotala wrote:
Andrew Dunstan píše v pá 09. 01. 2009 v 12:16 -0500:
Sure, we can easily have buildfarm's initdb step set any locale (and
encoding, for that matter) we like. That's a simple
On Mon, Jan 26, 2009 at 3:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Gregory Stark st...@enterprisedb.com writes:
Put another way, the choice here is whether to have a half-baked delayed 8.4
release in 6 months or a polished on-time 8.5 release in 12 months. Either
way
the feature ships and
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Jonah H. Harris wrote:
how can we expect this to change for 8.5? Can anyone point
out something Simon did wrong in this process?
Not really, except maybe started 6 months too late. Big patches simply
take a long time to mature.
On 1/26/09, Tom Lane t...@sss.pgh.pa.us wrote:
Gregory Stark st...@enterprisedb.com writes:
Put another way, the choice here is whether to have a half-baked delayed
8.4
release in 6 months or a polished on-time 8.5 release in 12 months. Either
way
the feature ships and on a not
On Mon, Jan 26, 2009 at 11:11 AM, Merlin Moncure mmonc...@gmail.com wrote:
What about a compromise solution: release 8.4 now, then focus on
wrapping up the big ticket items that didn't make it into 8.4 into a
quick (as possible) 8.5 release. This means no fests.
That would depend on timing
Dave Page dp...@pgadmin.org writes:
On Mon, Jan 26, 2009 at 3:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
This is pretty much exactly how I see it. *Hot standby is not ready*,
So can you give us an idea of what parts of the code are in need of
rethinking etc? I assume you've looked at it now
On Mon, Jan 26, 2009 at 4:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org writes:
On Mon, Jan 26, 2009 at 3:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
This is pretty much exactly how I see it. *Hot standby is not ready*,
So can you give us an idea of what parts of the
On Mon, Jan 26, 2009 at 04:40:12PM +0100, Albe Laurenz wrote:
Peter Eisentraut wrote:
I don't think that particular example is a good one since the
whole point of the archive is that it should be off-server. If
we're going to be exact about the example then we should give a
more realistic
Jonah H. Harris jonah.har...@gmail.com writes:
On Mon, Jan 26, 2009 at 11:11 AM, Merlin Moncure mmonc...@gmail.com wrote:
What about a compromise solution: release 8.4 now, then focus on
wrapping up the big ticket items that didn't make it into 8.4 into a
quick (as possible) 8.5 release. This
On 1/26/09, Jonah H. Harris jonah.har...@gmail.com wrote:
On Mon, Jan 26, 2009 at 11:11 AM, Merlin Moncure mmonc...@gmail.com wrote:
What about a compromise solution: release 8.4 now, then focus on
wrapping up the big ticket items that didn't make it into 8.4 into a
quick (as possible) 8.5
On Mon, Jan 26, 2009 at 11:33 AM, Tom Lane t...@sss.pgh.pa.us wrote:
That would depend on timing then. Trying to get people to upgrade to 8.4
is
going to be difficult if they're waiting on Hot Standby, which means less
in-the-field testing of the 8.4 code base until the 8.5 release.
[
Tom Lane t...@sss.pgh.pa.us wrote:
Jeff Davis pg...@j-davis.com writes:
There you see a snapshot of the table that never existed. Either
the
snapshot was taken before the UPDATE, in which case i=3 should be
included, or it was taken after the UPDATE, in which case i=4 should
be
included. So
pgtune is now on pgFoundry: http://pgfoundry.org/projects/pgtune/
I just released an update to there, and attached here for the archives is
that same code.
Progress since the last code drop to this list:
-All of the necessary integer handling needed was extracted from guc.c and
implemented,
Tom Lane t...@sss.pgh.pa.us writes:
Dave Page dp...@pgadmin.org writes:
On Mon, Jan 26, 2009 at 3:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
This is pretty much exactly how I see it. *Hot standby is not ready*,
So can you give us an idea of what parts of the code are in need of
rethinking
Simon Riggs wrote:
Rather than signalling, we could use a hasconflict boolean for each proc
in a shared data structure. It can be read without spinlock, but should
only be written while holding spinlock.
Each time we read a block we check if hasconflict is set. If it is, we
grab spinlock,
Dave Page wrote:
On Mon, Jan 26, 2009 at 4:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org writes:
On Mon, Jan 26, 2009 at 3:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
This is pretty much exactly how I see it. *Hot standby is not ready*,
So can you give us an idea of
On Mon, 2009-01-26 at 10:48 -0600, Kevin Grittner wrote:
I guess the issue of whether this violation of ACID properties should
be considered a bug or a feature is a separate discussion, but calling
it a feature seems like a hard sell to me.
I think I understand the other perspective on this
Jeff Davis pg...@j-davis.com wrote:
In fact, it's probably most similar to UPDATE ... RETURNING, which
will
give the same result (that breaks atomicity or isolation, depending
on
your point of view), which is correct for READ COMMITTED isolation
level.
READ COMMITTED is not supposed to be
Dave Page dp...@pgadmin.org writes:
On Mon, Jan 26, 2009 at 4:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
... (If you expect me to sign off on it you can
figure it'll be a couple of months even for that to happen...)
Well there is one of the problems imho - the project is getting too
big and
On Mon, Jan 26, 2009 at 11:44 AM, Jonah H. Harris
jonah.har...@gmail.com wrote:
On Mon, Jan 26, 2009 at 11:33 AM, Tom Lane t...@sss.pgh.pa.us wrote:
That would depend on timing then. Trying to get people to upgrade to
8.4 is
going to be difficult if they're waiting on Hot Standby, which
I think that's baked in the cards no matter what. IMO, the issue is
that code to review is building up faster than it is getting reviewed,
so maybe a festless release is nesessary to flush out the difference
(along with the other held over patches from 8.4).
How is that going to help?
Robert Haas wrote:
The other thing going on here is that HS is extremely important to the
project. If it was up to me, 100% effort would be geared to getting
it out as quickly as possible. I'm just looking for a way to get HS
in the hands of people as quickly as possible that is fair to
On Mon, 2009-01-26 at 12:47 -0500, Robert Haas wrote:
How is that going to help? People will still write new code in the
meanwhile and some of it may be better or more important than the
stuff that doesn't get committed to 8.4. Artificially saying that
nothing will be allowed for 8.5 that
On 2009-01-26, at 17:34, Kevin Grittner wrote:
. It may not
surprise someone who is intimately familiar with PostgreSQL internals
for a single SELECT statement to see PART of a transactions work, but
it would surprise most users, and is certainly not compliant with the
standard.
+1000
--
On Mon, 2009-01-26 at 11:34 -0600, Kevin Grittner wrote:
READ COMMITTED is not supposed to be able to view the work of a
concurrent transactions as PARTLY applied and PARTLY committed, which
is what's happening here. If one statement in a READ COMMITTED
transaction sees the uncommitted view
All,
So, some feedback to make this decision more difficult:
Users: care about HS more than anything else in the world. I'm
convinced that if we took a staw poll, 80% of our users would be in
favor of waiting for HS. This one feature will make more of a
difference in the number of PG users
Greg,
Things I was hoping for some input on:
-Using default_stats_target=100 doesn't seem controversial anymore,
which makes we wonder if it makes sense to restore the original DW
suggestion of 400 Josh suggested?
I'm going to back off from this. Following our discussion, I did some
Alvaro Herrera wrote:
Alvaro Herrera wrote:
I'm not sure that we have any use for the top level you propose; the
attached patch just uses the two lower levels, and I think it fits
autovacuum usage just fine. Thanks for the idea.
Of course, there's no need to pass the relkind; it goes
On Mon, 2009-01-26 at 11:36 -0800, Josh Berkus wrote:
All,
So, some feedback to make this decision more difficult:
Users: care about HS more than anything else in the world. I'm
convinced that if we took a staw poll, 80% of our users would be in
favor of waiting for HS. This one
On 1/26/09, Josh Berkus j...@agliodbs.com wrote:
All,
So, some feedback to make this decision more difficult:
Users: care about HS more than anything else in the world. I'm convinced
that if we took a staw poll, 80% of our users would be in favor of waiting
for HS. This one feature will
Jeff Davis pg...@j-davis.com wrote:
I don't think this is PostgreSQL-specific, I think non-MVCC database
systems face this same choice (although the terminology would be
different).
A somewhat dated description for Sybase (it predates their support of
row level locks and the related
Merlin,
Not completely. HS is in much better shape than win32 was when it was
pulled from 7.4...the build system wasn't even in place yet nor any of
the major challenges solved (like fork/exec).
HS is working very well (Simon's ongoing work aside). I am pretty
confident based on my personal
On Mon, Jan 26, 2009 at 2:36 PM, Josh Berkus j...@agliodbs.com wrote:
All,
So, some feedback to make this decision more difficult:
Users: care about HS more than anything else in the world. I'm convinced
that if we took a staw poll, 80% of our users would be in favor of waiting
for HS.
I wrote:
Simplified, in a READ COMMITTED transaction a SELECT takes a lock
which conflicts with update before reading, and holds it until the
executing statement is done with that table;
That should have said until after the executing statement completes.
Apologies, but but I just know
All,
1) having the last CF on Nov. 1 was a mistake. That put us square in the
path of the US Christian holidays during the critical integration phase ..
which means we haven't really had 3 months of integration, we've had *two*.
Actually, I'm thinking about this again, and made a mistake
Josh Berkus j...@agliodbs.com writes:
So, some feedback to make this decision more difficult:
Users: care about HS more than anything else in the world.
I don't think this is correct. There are certainly a lot of users who
would like an in-core replication solution, but HS by itself is not
On Mon, 2009-01-26 at 13:50 -0600, Kevin Grittner wrote:
A somewhat dated description for Sybase (it predates their support of
row level locks and the related predicate locks on indexes) is here:
Merlin Moncure mmonc...@gmail.com writes:
HS is working very well (Simon's ongoing work aside). I am pretty
confident based on my personal testing that it would represent the
project well if committed today.
I think a lot of people weren't aware there was anybody testing this patch
other
On 1/26/09, Josh Berkus j...@agliodbs.com wrote:
All,
1) having the last CF on Nov. 1 was a mistake. That put us square in the
path of the US Christian holidays during the critical integration phase
..
which means we haven't really had 3 months of integration, we've had
*two*.
Actually,
Jeff Davis pg...@j-davis.com wrote:
The tricky part is when an UPDATE with a search condition reads,
modifies, and writes a value that is used in a search condition for
another UPDATE.
Every DBMS will block waiting for the first UPDATE to finish. Then
what?
Either it's totally safe to
On 1/26/09, Gregory Stark st...@enterprisedb.com wrote:
Merlin Moncure mmonc...@gmail.com writes:
HS is working very well (Simon's ongoing work aside). I am pretty
confident based on my personal testing that it would represent the
project well if committed today.
I think a lot of
Gregory Stark st...@enterprisedb.com writes:
Here's a thought experiment. If it was committable *today* would we be
willing to go with it and plan to release with it? Assume that it
would *still* mean a longer beta process, so it would still mean
releasing in, say April instead of February or
On Mon, 2009-01-26 at 14:31 -0600, Kevin Grittner wrote:
Do you re-run the query to find new tuples that might now satisfy
the search condition that didn't before?
There can't be any. Blocks taken during the reading of rows so far
have not been released, and would preclude the update
bgrosper...@laposte.net
Bernard Grosperrin
BGSoftFactory
Bureau/Domicile 09 53 41 58 18
Mobile 06 75 13 97 17
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, 2009-01-26 at 20:12 +, Gregory Stark wrote:
Merlin Moncure mmonc...@gmail.com writes:
HS is working very well (Simon's ongoing work aside). I am pretty
confident based on my personal testing that it would represent the
project well if committed today.
I think a lot of
Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
So, some feedback to make this decision more difficult:
Users: care about HS more than anything else in the world.
I don't think this is correct. There are certainly a lot of users who
would like an in-core replication solution, but HS
Jeff Davis pg...@j-davis.com wrote:
On Mon, 2009-01-26 at 14:31 -0600, Kevin Grittner wrote:
Do you re-run the query to find new tuples that might now satisfy
the search condition that didn't before?
There can't be any. Blocks taken during the reading of rows so far
have not been
Jeff Davis pg...@j-davis.com writes:
It seems like it would be a challenge to know that the tuple with i=3
would be updated to a value that matches the search condition j=10. So
can you tell me a little more about the mechanism by which Sybase solves
this problem?
This example is a case of
On Mon, 2009-01-26 at 15:47 -0500, Merlin Moncure wrote:
I'd also like to see Simon and or
Heikki make a strong statement on where things stand _right now_ (not
in two weeks) :-)
Well, we just found 2 bugs over the weekend, one of which is a
regression from refactoring.
The second bug is
On Mon, 2009-01-26 at 15:49 -0500, Tom Lane wrote:
The problem is that it's not ready and no one is very sure about when
it will be.
With respect, I've done more than any other developer has done to give
you and the community full information on the patch as it develops. I'm
sorry you don't
Josh Berkus wrote:
All,
So, some feedback to make this decision more difficult:
Users: care about HS more than anything else in the world. I'm
convinced that if we took a staw poll, 80% of our users would be in
favor of waiting for HS. This one feature will make more of a
difference in
Joshua,
So the security model has been looked at, though not the implementation
and we do have a community of developers, users and customers interested
in this work.
Can you please take a look at it ASAP, then? In the next week, we will
probably decide on whether or not to defer
On Monday 26 January 2009 2:12:02 pm Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
So, some feedback to make this decision more difficult:
Users: care about HS more than anything else in the world.
I don't think this is correct. There are certainly a lot of users who
would like
Gregory Stark st...@enterprisedb.com wrote:
This example is a case of the same issue we were discussing earlier
involving predicate locking. To solve it you need a way to lock
records that your query *isn't* accessing and may not even exist yet
to prevent them from being turned into (or
On 1/26/09 4:28 PM, Joshua Brindle met...@manicmethod.com wrote:
Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
snip
SE-Linux: this patch has effectively been in development for 2 years
ourside the core process before putting it in; the forked SEPostgres is
in use in production.
On Mon, 2009-01-26 at 09:26 -0800, Jeff Davis wrote:
On Mon, 2009-01-26 at 10:48 -0600, Kevin Grittner wrote:
I guess the issue of whether this violation of ACID properties should
be considered a bug or a feature is a separate discussion, but calling
it a feature seems like a hard sell to
Gregory Stark wrote:
I think a lot of people weren't aware there was anybody testing this patch
other than Simon and Heikki -- I wasn't until just today. I wonder how many
more people are trying it out?
I've been running the patch (I think since Jan 5) on a couple dev instances
that were
Tom Lane wrote:
Bernd Helmle maili...@oopsware.de writes:
Or what about
CREATE [OR REPLACE] [UPDATABLE] VIEW ... ?
This looks closer to TEMP|TEMPORARY VIEW, which we already have.
But per spec, UPDATABLE should be the default (if not now, then
eventually). Are you proposing
On Mon, Jan 26, 2009 at 5:18 PM, Bruce Momjian br...@momjian.us wrote:
Tom Lane wrote:
Bernd Helmle maili...@oopsware.de writes:
Or what about
CREATE [OR REPLACE] [UPDATABLE] VIEW ... ?
This looks closer to TEMP|TEMPORARY VIEW, which we already have.
But per spec, UPDATABLE should be the
Bruce Momjian wrote:
Tom Lane wrote:
Bernd Helmle maili...@oopsware.de writes:
Or what about
CREATE [OR REPLACE] [UPDATABLE] VIEW ... ?
This looks closer to TEMP|TEMPORARY VIEW, which we already have.
But per spec, UPDATABLE should be the default (if not now, then
eventually). Are you
Josh Berkus wrote:
Joshua,
So the security model has been looked at, though not the
implementation and we do have a community of developers, users and
customers interested in this work.
Can you please take a look at it ASAP, then? In the next week, we will
probably decide on whether or
create table a(a_id serial primary key, a int);
create table b(b_id serial primary key, a_id int not null references a
(id), b int, c_id int not null references c(id));
NOTICE: CREATE TABLE will create implicit sequence b_id_seq for
serial column b.b_id
NOTICE: CREATE TABLE / PRIMARY KEY
Gregory Stark wrote:
I think a lot of people weren't aware there was anybody testing this patch
...I wonder how many more people are trying it out?
I think I have an idea to improve this aspect for future commit fests.
For a long time at each of my workplaces I've been running a development
On Mon, Jan 26, 2009 at 5:42 PM, Ron Mayer
rm...@cheapcomplexdevices.com wrote:
I realize in the current system (emailed patches), this would be a horrible
pain to maintain such a branch; but perhaps some of the burden could be
pushed down to the patch submitters (asking them to merge their own
Ron Mayer rm...@cheapcomplexdevices.com writes:
I realize in the current system (emailed patches), this would be a horrible
pain to maintain such a branch; but perhaps some of the burden could be
pushed down to the patch submitters (asking them to merge their own changes
into this merged
Christopher Browne wrote:
On Mon, Jan 26, 2009 at 5:42 PM, Ron Mayer
rm...@cheapcomplexdevices.com wrote:
There has been enough experimentation with git usage during the 8.4 ...
I certainly didn't mean for the idea to be advocating git nor any
changes in 8.4.
I was hoping the main idea was
Joshua Brindle met...@manicmethod.com writes:
Yes, I will look at them to the extent I am able. As I am not familiar with
the
postgresql codebase I won't be able to assert the correctness of the hook
placement (that is, where the security functions are called with respect to
the
data they
1 - 100 of 153 matches
Mail list logo
