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
int,
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
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.
BM Yes,
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 substitute
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 INSERT, and
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
JConly one row, else zero
I don't agree with this one since it would lead us to a meaningless
information... what would be
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
JConly one row, else zero
I don't agree with this one since it would lead us to a meaningless
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 affected by all
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 at least
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 doing it
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 is
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 work. There
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.
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 is that
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
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
return sum of
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
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
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 of original command
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
if
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 of original
29 matches
Mail list logo
