Tom Lane wrote:
I would think this is overkill, except I've made the same darn mistake
one time too many. It seems clear to me that a lot of other people will
make it too, and if the error message isn't more helpful a lot of time
will get wasted. Barring loud objections, I'm gonna go change it.
This is now the first entry on the new 8.4 Open Items list:
http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items
--
* Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscripti
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 http://wiki.postgresql.org/wi
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 thin
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 qu
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-hackers&m=12470930544&w=2
Getting consensus on a design seems to actually be one of the harde
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
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 expo
> 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
particul
> > 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 rewrit
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
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 restore
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
Po
Quick, what's wrong with this query?
regression=# with q(x) as (select 1 union all select x+1 from q where x<10)
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 x<1...
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 i
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:
>
>> He
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
>>>
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 8
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
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 advan
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 updates
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:
O
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
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 a
>> 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
mana
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
transac
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 C
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
> th
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 Smi
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 cou
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 de
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 relfile
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 a
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
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, 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 w
"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 pr
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
> > honkin
>> 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
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
> toast_flatten_tuple_at
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 so
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 b
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
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 ar
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 syst
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?
> 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
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
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 re
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 PR
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.
Anythin
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
permissio
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
> > fairl
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 c
54 matches
Mail list logo
