On Mon, 2008-10-06 at 18:57 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
It seems possible to change some DDL commands/subcommands to use a
ShareLock rather than an AccessExclusiveLock. Enclosed patch implements
this reduction for CREATE TRIGGER, CREATE RULE and ALTER
Emmanuel Cecchet wrote:
Instead of relying on a boolean that tells if a temp table was accessed,
I keep a list of the Oid for the temp tables accessed in the transaction
and at prepare commit time, I check if the relations are still valid. I
also added a check to allow empty temp tables at
Tom Lane wrote:
Greg Smith [EMAIL PROTECTED] writes:
When I was looking at this code for the first time recently I thought the
same thing Tom did here--that this was kind of odd and it should give a
text array back instead. I would even volunteer to take a stab at writing
that change
On Thu, 2008-10-02 at 19:07 -0400, Andrew Dunstan wrote:
Simon Riggs wrote:
Just seen this patch has been bounced into November CommitFest, even
though the new patch fixes all of the concerns raised.
I'm concerned that this is going to make the final Hot Standby patch
fairly large,
On Sun, 2008-10-05 at 14:51 -0400, Alvaro Herrera wrote:
Simon Riggs wrote:
OK, spent long time testing various batching scenarios for this using a
custom test harness to simulate various spreads of xids in transaction
trees. All looks fine now.
I had a look and was mostly rephrasing
On Tue, 2008-10-07 at 08:30 -0400, Andrew Dunstan wrote:
Simon Riggs wrote:
My main focus is on these commands
* CREATE TRIGGER
* ALTER TABLE .. ADD PRIMARY KEY
* ALTER TABLE .. ADD FOREIGN KEY
because those are the most painful ones. We could make it work against
more, but
3. The patch introduces a slight weirdness: if you create two FKs on the
same column at the same time you end up with two constraints with
identical names. Drop constraint then removes them both, though in other
respects they are both valid, just not uniquely. CREATE INDEX avoids
this by way
I'm trying write tuple conversion function and now I'm hit problem with
composite data types. Composite data types can contain inner composite
data types. Is there any limit? And I found that heap_form_tuple calls
toast_flatten_tuple_attribute only one level composite type. Is it bug?
Simon Riggs [EMAIL PROTECTED] writes:
A patch specifically marked as required for other work has been
delayed by more than 5 weeks on queue and nobody was ever assigned to
review it. That was exactly the problem CommitFests were supposed to
resolve and from my perspective this is a systemic
On Tue, 2008-10-07 at 10:05 -0400, Robert Haas wrote:
3. The patch introduces a slight weirdness: if you create two FKs on the
same column at the same time you end up with two constraints with
identical names. Drop constraint then removes them both, though in other
respects they are both
On Tue, 2008-10-07 at 10:08 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
A patch specifically marked as required for other work has been
delayed by more than 5 weeks on queue and nobody was ever assigned to
review it. That was exactly the problem CommitFests were supposed
Simon Riggs [EMAIL PROTECTED] writes:
On Tue, 2008-10-07 at 10:05 -0400, Robert Haas wrote:
3. The patch introduces a slight weirdness: if you create two FKs on the
same column at the same time you end up with two constraints with
identical names. Drop constraint then removes them both, though
Simon Riggs wrote:
I'm just grumpy because I can't see a way to do the
patch-on-patch-on-patch that I'll need to make this all work for Nov 1.
So big patch here we come. But that's just the way it is and I'll stop
honking about it.
This is one of the problems that DVCSs are supposed to solve
Zdenek Kotala [EMAIL PROTECTED] writes:
I'm trying write tuple conversion function and now I'm hit problem with
composite data types. Composite data types can contain inner composite
data types. Is there any limit?
No.
And I found that heap_form_tuple calls
I'm just grumpy because I can't see a way to do the
patch-on-patch-on-patch that I'll need to make this all work for Nov 1.
So big patch here we come. But that's just the way it is and I'll stop
honking about it.
This is one of the problems that DVCSs are supposed to solve ... have
you
On Tue, 2008-10-07 at 07:21 +0100, Simon Riggs wrote:
It was an excellent question because that aspect isn't handled correctly
in the enclosed patch for subcommands, other than index-creating
constraints.
My main focus is on these commands
* CREATE TRIGGER
* ALTER TABLE .. ADD PRIMARY
Simon Riggs wrote:
My main focus is on these commands
* CREATE TRIGGER
* ALTER TABLE .. ADD PRIMARY KEY
* ALTER TABLE .. ADD FOREIGN KEY
because those are the most painful ones. We could make it work against
more, but we'd need to rewrite lots and lots of catalog update code.
On Tue, 2008-10-07 at 10:37 -0400, Alvaro Herrera wrote:
Simon Riggs wrote:
I'm just grumpy because I can't see a way to do the
patch-on-patch-on-patch that I'll need to make this all work for Nov 1.
So big patch here we come. But that's just the way it is and I'll stop
honking about
Robert Haas [EMAIL PROTECTED] writes:
I'm just grumpy because I can't see a way to do the
patch-on-patch-on-patch that I'll need to make this all work for Nov 1.
So big patch here we come. But that's just the way it is and I'll stop
honking about it.
This is one of the problems that DVCSs
On Tue, 2008-10-07 at 10:35 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Tue, 2008-10-07 at 10:05 -0400, Robert Haas wrote:
3. The patch introduces a slight weirdness: if you create two FKs on the
same column at the same time you end up with two constraints with
Simon Riggs [EMAIL PROTECTED] writes:
2. Also need to decide whether we want pg_class.reltriggers as int2 (as
implemented here) or switch to relhastriggers as boolean.
I'd go for changing the column name/type. Yeah, you will break any
clients that are still trying to manipulate reltriggers
On Tue, Oct 7, 2008 at 4:08 PM, Simon Riggs [EMAIL PROTECTED] wrote:
Not convinced this is the right time to invest in side activities, but
if you think so, I'll look into it.
Anybody wanting to write or link to a Simon's Guide, most welcome.
Heikki will be presenting a talk about GIT + PG
Alvaro Herrera wrote:
Simon Riggs wrote:
I'm just grumpy because I can't see a way to do the
patch-on-patch-on-patch that I'll need to make this all work for Nov 1.
So big patch here we come. But that's just the way it is and I'll stop
honking about it.
This is one of the problems that DVCSs
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Yeah, seems like we need to allocate a new relfilenode in the new
tablespace.
I looked into tablecmds.c and verified that ATExecSetTableSpace doesn't
worry about selecting a new relfilenode. I'm also noticing a number of
Heikki Linnakangas a écrit :
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Yeah, seems like we need to allocate a new relfilenode in the new
tablespace.
I looked into tablecmds.c and verified that ATExecSetTableSpace doesn't
worry about selecting a new relfilenode. I'm also
Simon Riggs [EMAIL PROTECTED] writes:
On Tue, 2008-10-07 at 10:35 -0400, Tom Lane wrote:
I wonder whether this could be helped if we refactored pg_constraint.
Sounds better. Doesn't make much sense as it is now.
I looked at the code a bit, and it seems the only place where the
current design
On Tue, 2008-10-07 at 18:19 +0300, Heikki Linnakangas wrote:
The bottom line is that hot standby is a big feature, and probably a big
patch. No amount of version control will work around that. Finishing all
that in a few weeks is a very ambitious goal. I wish you luck, and I
wish I could
On Tue, 7 Oct 2008, Magnus Hagander wrote:
Might this be the time to add an open items for 8.4 page to the wiki?
There's already:
http://wiki.postgresql.org/wiki/Todo:WishlistFor84
Which was aimed at being a live version of that, but was superseded by the
CommitFest pages.
--
* Greg
Greg Smith wrote:
On Tue, 7 Oct 2008, Magnus Hagander wrote:
Might this be the time to add an open items for 8.4 page to the wiki?
There's already:
http://wiki.postgresql.org/wiki/Todo:WishlistFor84
Which was aimed at being a live version of that, but was superseded by
the CommitFest
Greg Smith wrote:
On Tue, 7 Oct 2008, Magnus Hagander wrote:
Might this be the time to add an open items for 8.4 page to the wiki?
There's already:
http://wiki.postgresql.org/wiki/Todo:WishlistFor84
Which was aimed at being a live version of that, but was superseded by
the CommitFest
Hi Heikki,
The patch allows preparing any transaction that has dropped the temp
table, even if it wasn't created in the same transaction. Is that sane?
If you have a temp table created with an 'on commit delete rows' option
in another transaction, it would be fine to drop it in another
Urk... this seems pretty undesirable.
OK, but please say what behaviour you would like in its place.
Or are you saying you dislike this so much that you would prefer not to
be able to run ALTER TABLE concurrently?
Personally, yes. I work mostly with small databases where ease of
management
On Tue, 2008-10-07 at 11:46 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Tue, 2008-10-07 at 10:35 -0400, Tom Lane wrote:
I wonder whether this could be helped if we refactored pg_constraint.
Sounds better. Doesn't make much sense as it is now.
I looked at the code a
Simon Riggs [EMAIL PROTECTED] writes:
How about we put a partial unique index on instead?
We don't currently support partial indexes on system catalogs.
I forget what all would need to be fixed to make it happen, but I'm
pretty sure it's not trivial. Certainly refactoring pg_constraint
would be
We can't do partial indexes on system tables. I forget exactly why nut
if you search for relevant comments it should pop up.
greg
On 7 Oct 2008, at 07:38 PM, Simon Riggs [EMAIL PROTECTED] wrote:
On Tue, 2008-10-07 at 11:46 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On
On 2008-10-06, at 20:59, Grzegorz Jaskiewicz wrote:
Hey folks,
I would like to learn more about execution path for a simple query,
that is going to be changed by a rule. I want to find out, why
output of 'affected rows' isn't always altered properly in rules
rewriting inserts and
Heikki,
Here is a new version of the patch using a hash table as you suggested.
I also include the tests that I have added to the regression test suite
to test the various scenarios.
All patches are based on Postgres 8.3.3, let me know if you want me to
generate patch for 8.4.
Thanks in
On Tue, Oct 07, 2008 at 04:57:37PM -0400, Emmanuel Cecchet wrote:
Heikki,
Here is a new version of the patch using a hash table as you
suggested. I also include the tests that I have added to the
regression test suite to test the various scenarios. All patches
are based on Postgres 8.3.3,
Hi,
On Tue, Oct 07, 2008 at 04:57:37PM -0400, Emmanuel Cecchet wrote:
Heikki,
Here is a new version of the patch using a hash table as you
suggested. I also include the tests that I have added to the
regression test suite to test the various scenarios. All patches
are based on Postgres
On Tue, Oct 07, 2008 at 06:12:14PM -0400, Emmanuel Cecchet wrote:
Hi,
On Tue, Oct 07, 2008 at 04:57:37PM -0400, Emmanuel Cecchet wrote:
Heikki,
Here is a new version of the patch using a hash table as you
suggested. I also include the tests that I have added to the
regression test
This is not a support list. Sounds like you should consider
purchasing a commercial support contract, or you could try asking on
pgsql-general.
...Robert
On Tue, Oct 7, 2008 at 4:30 PM, Grzegorz Jaskiewicz [EMAIL PROTECTED] wrote:
On 2008-10-06, at 20:59, Grzegorz Jaskiewicz wrote:
Hey
KaiGai Kohei wrote:
Bruce Momjian wrote:
2) Do we want row-level permissions at the SQL level?
Now I'm working for it and will submit patches due to the end of Oct,
if it is really required to make progress reviewing of SE-PostgreSQL
on the v8.4 development cycle.
However, the scale of
Quick, what's wrong with this query?
regression=# with q(x) as (select 1 union all select x+1 from q where x10)
regression-# select * from q;
ERROR: relation q does not exist
LINE 1: with q(x) as (select 1 union all select x+1 from q where x1...
KaiGai,
If I can understand correctly, we don't have a clear conclusion of this.
So, it is unclear for me whether the row-level permission at SQL level
is necessary to progress the reviewing process of SE-PostgreSQL, or not.
Can you *do* the row-level permission?
--
--Josh
Josh Berkus
Attached is the latest version of my parallel restore work.
In this version pg_dump has learned how to tag each item with the
section it belongs to (data, pre-data, post-data). That removes the
necessity for hardcoding knowledge about the boundary of the data
section into the parallel
Josh Berkus wrote:
KaiGai,
If I can understand correctly, we don't have a clear conclusion of this.
So, it is unclear for me whether the row-level permission at SQL level
is necessary to progress the reviewing process of SE-PostgreSQL, or not.
Can you *do* the row-level permission?
I think
On 2008-10-06, at 20:59, Grzegorz Jaskiewicz wrote:
Hey folks,
I would like to learn more about execution path for a simple query, that
is going to be changed by a rule. I want to find out, why output of
'affected rows' isn't always altered properly in rules rewriting inserts
and
Can you *do* the row-level permission?
I don't think there's any consensus on a design.
Getting consensus on a design seems to actually be one of the harder
aspects of PostgreSQL development. The pattern seems to be:
1. Someone submits a patch. By definition, the patch embodies some
I looked a bit at the SQL:2008 spec for a CYCLE clause for WITH
RECURSIVE. It is interesting to see that it is just syntactic sugar,
because *they spell out how to expand it into regular SQL*. More,
they defined it in such a way that it's hard to optimize at all,
because the path column is
Hi,
Here are the patches for 8.4 (1 patch for the code and 1 patch for the
regression tests).
Thanks in advance for your feedback,
Emmanuel
David Fetter wrote:
On Tue, Oct 07, 2008 at 06:12:14PM -0400, Emmanuel Cecchet wrote:
Hi,
On Tue, Oct 07, 2008 at 04:57:37PM -0400, Emmanuel
Robert Haas wrote:
Can you *do* the row-level permission?
I don't think there's any consensus on a design.
Yes, unfortunatelly.
No one replied to my proposed design:
http://marc.info/?l=pgsql-hackersm=12470930544w=2
Getting consensus on a design seems to actually be one of the harder
Thanks. Now the header file include issues resolved. I fetch the latest code
and no such issues.
But I found new issues now. (the latest code from cvs)
1. file : contrib\fuzzystrmatch\dmetaphone.c,
line: 1040 and line: 464, both look like as below,
case '?:
There is no the matched single
Tom Lane [EMAIL PROTECTED] writes:
What we can do is keep a list of not yet parsed WITH-names in ParseState,
and check through that list when about to fail for relation-not-found, and
issue a suitable message hinting that maybe you forgot RECURSIVE if we find
a match.
I would think this is
On 2008-10-08, at 01:57, Alvaro Herrera wrote:
Actually I find this to be a perfectly acceptable question for this
list. ISTM the answer, however, is to have a look at the
documentation
we have already in place ... perhaps starting with the Developer's FAQ
at
54 matches
Mail list logo
