Hi,
I didn't download the beta but compared the CVS checkouts and it appears
the ecpg directory is still the one from 7.2 not the one tagged
big_bison. Will this one be moved into the mainstream source? Else we
would be stuck with a non-compatible parser.
If I shall move it, please tell me, I'm
On Sat, 07 Sep 2002 10:26:36 -0700
Joe Conway <[EMAIL PROTECTED]> wrote:
>
> OK -- patch submitted to fix this. Once the patch is applied, this case
> gives:
>
> test=# SELECT * FROM connectby('connectby_tree', 'keyid',
> 'parent_keyid', '2', 0, '~') AS t(keyid int, parent_keyid int, level
>
Hi,
Sorry to insist, may be my previus subject was miss understood ...
refering to this message :
http://archives.postgresql.org/pgsql-hackers/2002-09/msg00461.php
But I can't import my data from 7.2.2 into 7.3b1 ...
1- Many errors during importation of the data
2- Seems to use all the memory (a
Hello Bruce,
Monday, September 9, 2002, 12:16:32 AM, you wrote:
BM> Joe Conway wrote:
BM> Any suggestion on how to show the tag mutated? Do we want to add more
BM> tag possibilities?
Again, I don't agree with PQcmdStatus() returning a pseudo-keyword,
since I would expect a SQL command executed
Hello Bruce,
Monday, September 9, 2002, 12:21:11 AM, you wrote:
BM> Steve Howe wrote:
>> Hello Bruce,
>>
>> But this *is* the total number of rows affected. There is no current
>> (defined) behavior of "rows affected by the same kind of command
>> issued", although I agree it makes some sense.
Bruce Momjian wrote:
> Joe Conway wrote:
>>This is basically Tom's proposal, but substituting MUTATED for the
>>original command tag name acknowledges that the original command was not
>> executed unchanged. It also serves as a warning that the affected
>>tuple count is from one or more substi
Steve Howe wrote:
> We still have to hear the other developers about this, but for a
> while, my votes go to Proposal's #2 (by Tom) and Proposal #3 if enough
> people consider it important.
I think Tom and Hirosh were the people most involved in the previous
discussion.
--
Bruce Momjian
Joe Conway wrote:
> Sure, but that's why I am in favor of changing the tag. If you did:
>
> DELETE FROM fooview WHERE name LIKE 'Joe%';
>
> and got:
>
> MUTATED 507324 3
>
> it would mean that 3 tuples in total were affected by all of the
> substitute operations, only of of them being an INSE
Hello Bruce,
Monday, September 9, 2002, 12:22:26 AM, you wrote:
BM> Steve Howe wrote:
>> JC> return OID if sum of all replacement INSERTs in the rule inserted
>> JC>only one row, else zero
>> I don't agree with this one since it would lead us to a meaningless
>> information... what
Steve Howe wrote:
> Hello Bruce,
>
> Monday, September 9, 2002, 12:22:26 AM, you wrote:
>
> BM> Steve Howe wrote:
> >> JC> return OID if sum of all replacement INSERTs in the rule inserted
> >> JC>only one row, else zero
> >> I don't agree with this one since it would lead us to a m
Hello Bruce,
Monday, September 9, 2002, 12:36:38 AM, you wrote:
BM> Joe Conway wrote:
>> Sure, but that's why I am in favor of changing the tag. If you did:
>>
>> DELETE FROM fooview WHERE name LIKE 'Joe%';
>>
>> and got:
>>
>> MUTATED 507324 3
>>
>> it would mean that 3 tuples in total were
Bruce Momjian wrote:
> OK. Do any people have INSTEAD rules where there are not commands
> matching the original query tag? Can anyone think of such a case being
> created?
>
> The only one I can think of is UPDATE implemented as separate INSERT and
> DELETE commands.
>
I could see an UPDATE
Hello Bruce,
Monday, September 9, 2002, 12:39:20 AM, you wrote:
>> BM> I don't understand this objection.
>> I misunderstood Joe's statement into thinking we wanted to sum the
>> OIDs for all INSERT commands applied :)
>> Please ignore this.
>> But now that I read it again, I would prefer having
Steve Howe wrote:
> BM> We would return 0 for oid and an insert count, just like INSERT INTO ...
> BM> SELECT. How is that weird?
> It's not weird, or as weird as the other proposal which is retrieving
> the last inserted OID number. If we can return some information for
> the client, why not doi
On Sun, 8 Sep 2002, Steve Howe wrote:
> Here are the proposals for solutioning the "Return proper effected
> tuple count from complex commands [return]" issue as seen on TODO.
>
> Any comments ?... This is obviously open to voting and discussion.
As it seems we're voting, I think Tom's scheme i
Because we have seen many complains about sequential vs index scans, I
wrote a script which computes the value for your OS/hardware
combination.
Under BSD/OS on one SCSI disk, I get a random_page_cost around 60. Our
current postgresql.conf default is 4.
What do other people get for this value?
Tom Lane wrote:
> Sean Chittenden <[EMAIL PROTECTED]> writes:
>
>>::sigh:: Is it me or does it look like all
>>of pl/pgsql is schema un-aware (ie, all of the declarations). -sc
>
>
> Yeah. The group of routines parse_word, parse_dblword, etc that are
> called by the lexer certainly all need w
OK, turns out that the loop for sequential scan ran fewer times and was
skewing the numbers. I have a new version at:
ftp://candle.pha.pa.us/pub/postgresql/randcost
I get _much_ lower numbers now for random_page_cost.
---
I got:
random_page_cost = 0.807018
For FreeBSD 4.4/i386
With 512MB RAM & SCSI HDD
Chris
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Bruce Momjian
> Sent: Monday, 9 September 2002 2:14 PM
> To: PostgreSQL-development
> Subject: Re: [HACKERS]
Matthew T. O'Connor wrote:
> On Saturday 07 September 2002 12:52 pm, Bruce Momjian wrote:
> > Peter Eisentraut wrote:
> > > Didn't we want to remove that option?
> >
> > I didn't know it was still in there. I see no reason for it.
>
> How about --enable-depend, that's not still needed is it? Or
Hello all,
Here are the proposals for solutioning the "Return proper effected
tuple count from complex commands [return]" issue as seen on TODO.
Any comments ?... This is obviously open to voting and discussion.
--
Best regards,
Steve Howe mailto:[EMAIL PROTECTED]
I liked option #2. I don't think the _last_ query in a rule should have
any special handling.
So, to summarize #2, we have:
if no INSTEAD,
return value of original command
if INSTEAD,
return tag of original command
return sum of all affected rows with
Hi Guys,
You might be interested in the results of the Australian Open Source Awards:
http://www.smh.com.au/articles/2002/09/06/1031115931961.html
Justin Clift and I both rated mentions - Justin for the Postgres websites
and myself for BSD Users Group WA.
One good things is that both Postgres
Bruce Momjian wrote:
> I liked option #2. I don't think the _last_ query in a rule should have
> any special handling.
>
> So, to summarize #2, we have:
>
> if no INSTEAD,
> return value of original command
>
> if INSTEAD,
> return tag of original command
> retu
God, I wish ppl would at least get information correct :(
Justin Clift (for the postgreSQL documentation website)
the website they point to *isn't* techdocs, but www, which Justin has had
nothing to do with ;(
On Mon, 9 Sep 2002, Christopher Kings-Lynne wrote:
> Hi Guys,
>
> You might be inte
Well annoyingly enough they have me down as 'founding pandaemonium' whereas
it should be co-founded pandaemonium :(
Chris
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Marc G. Fournier
> Sent: Monday, 9 September 2002 11:01 AM
> To: Christopher K
Hello Bruce,
Sunday, September 8, 2002, 10:52:45 PM, you wrote:
BM> I liked option #2. I don't think the _last_ query in a rule should have
BM> any special handling.
BM> So, to summarize #2, we have:
BM> if no INSTEAD,
BM> return value of original command
The problem is, this
Joe Conway wrote:
> Bruce Momjian wrote:
> > I liked option #2. I don't think the _last_ query in a rule should have
> > any special handling.
> >
> > So, to summarize #2, we have:
> >
> > if no INSTEAD,
> > return value of original command
> >
> > if INSTEAD,
> > return tag
Hello Joe,
Sunday, September 8, 2002, 11:54:45 PM, you wrote:
JC> Bruce Momjian wrote:
>> I liked option #2. I don't think the _last_ query in a rule should have
>> any special handling.
>>
>> So, to summarize #2, we have:
>>
>> if no INSTEAD,
>> return value of original command
Steve Howe wrote:
> Hello Bruce,
>
> Sunday, September 8, 2002, 10:52:45 PM, you wrote:
>
> BM> I liked option #2. I don't think the _last_ query in a rule should have
> BM> any special handling.
>
> BM> So, to summarize #2, we have:
>
> BM> if no INSTEAD,
> BM> return value
Steve Howe wrote:
> JC> return OID if sum of all replacement INSERTs in the rule inserted
> JC>only one row, else zero
> I don't agree with this one since it would lead us to a meaningless
> information... what would be the number retrieved ? Not an OID, nor
> nothing.
I don't unders
31 matches
Mail list logo
