Re: [HACKERS] Why isn't DECLARE CURSOR ... FOR UPDATE supported?

2003-12-19 Thread Hiroshi Inoue
haven't supported updatable cursors yet. regards, Hiroshi Inoue ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [HACKERS] CLUSTER ALL syntax

2002-11-17 Thread Hiroshi Inoue
Alvaro Herrera wrote: On Sun, Nov 17, 2002 at 06:43:38PM -0500, Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: And what about REINDEX? That seems to have a different syntax from the other two. Seems there should be some

Re: [HACKERS] MOVE LAST: why?

2003-01-07 Thread Hiroshi Inoue
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Refresh my memory: what is the point of inventing an additional LAST keyword, when the behavior is exactly the same as MOVE ALL ? SQL compatibility, per Peter. Oh, I see. But then

Re: [HACKERS] MOVE LAST: why?

2003-01-07 Thread Hiroshi Inoue
Tom Lane wrote: Sure. FETCH n in Postgres has always corresponded to FETCH RELATIVE n. IIRC in SQL standard FETCH retrieves rows one by one. regards, Hiroshi Inoue http://w2422.nsk.ne.jp/~inoue/ ---(end of

Re: [HACKERS] MOVE LAST: why?

2003-01-07 Thread Hiroshi Inoue
Tom Lane wrote: Hiroshi Inoue [EMAIL PROTECTED] writes: Tom Lane wrote: Sure. FETCH n in Postgres has always corresponded to FETCH RELATIVE n. IIRC in SQL standard FETCH retrieves rows one by one. Yes, Postgres' idea of FETCH is only weakly related

Re: [HACKERS] MOVE LAST: why?

2003-01-08 Thread Hiroshi Inoue
Tom Lane wrote: Hiroshi Inoue [EMAIL PROTECTED] writes: FETCH LAST should return the last one row. That's not clear to me. Generally, I would think the cursor should remain positioned on whatever row is returned, but the spec clearly says that the final cursor

Re: [HACKERS] MOVE LAST: why?

2003-01-08 Thread Hiroshi Inoue
Tom Lane wrote: Perhaps we could do something with a hybrid technique: don't materialize the cursor output unless user actually asks for backwards scan. Or we can check the existence of SCROLL keyword which is currently ignored. In the first place SQL standard only

Re: [HACKERS] MOVE LAST: why?

2003-01-08 Thread Hiroshi Inoue
Zeugswetter Andreas SB SD wrote: FETCH LAST should return the last one row. FETCH RELATIVE m should return a row after skipping m rows if we follow the SQL standard and so the current implementation of FETCH RELATIVE is broken. Yes, the syntax could probably be

Re: [HACKERS] MOVE LAST: why?

2003-01-08 Thread Hiroshi Inoue
Tom Lane wrote: Hiroshi Inoue [EMAIL PROTECTED] writes: I'm suspicios if we should implement scrollable cursors with the combination of the current MOVE and FETCH implemen- tation. For example the backwards FETCH operation for group nodes isn't implemented properly yet

Re: [HACKERS] MOVE LAST: why?

2003-01-12 Thread Hiroshi Inoue
Honestly I'm not so enthusiastic about scrollable cursors. Even though PostgreSQL provides an efficient scrollable cursor, I would use it little unless it could survive across transactions. Anyway it's too bad that FETCH LAST means FETCH ALL. I would remove LAST,

Re: [HACKERS] MOVE LAST: why?

2003-01-12 Thread Hiroshi Inoue
Bruce Momjian wrote: Hiroshi Inoue wrote: Honestly I'm not so enthusiastic about scrollable cursors. Even though PostgreSQL provides an efficient scrollable cursor, I would use it little unless it could survive across transactions. Anyway it's too bad

Re: [HACKERS] MOVE LAST: why?

2003-02-03 Thread Hiroshi Inoue
Bruce Momjian wrote: It also clarifies the docs to mention it sits on the last row, not after the last row. Is it true ? regards, Hiroshi Inoue http://www.geocities.jp/inocchichichi/psqlodbc/ ---(end of

[HACKERS] A bad behavior under autocommit off mode

2003-02-19 Thread Hiroshi Inoue
Hi all, There seems a bad behavior under autocommit off mode. 1) psql -c 'set autocommit to off;select 1;commit' causes a WARNING: COMMIT: no transaction in progress whereas 2) psql -c 'begin;select 1;commit' causes no error/warning. Note that the result is

Re: [HACKERS] A bad behavior under autocommit off mode

2003-02-20 Thread Hiroshi Inoue
Tom Lane wrote: "Hiroshi Inoue" [EMAIL PROTECTED] writes: The simplest way seems to accept COMMIT any time under autocommit off mode. That's just hiding the most visible symptom. The real problem here is that the SELECT is already committed, when it

Re: [HACKERS] Detecting corrupted pages earlier

2003-02-18 Thread Hiroshi Inoue
Tom Lane wrote: Hiroshi Inoue [EMAIL PROTECTED] writes: Tom Lane wrote: I'm thinking of modifying ReadBuffer() so that it errors out if the What does the *error out* mean ? Mark the buffer as having an I/O error and then elog(ERROR). Is there a way

Re: [HACKERS] Detecting corrupted pages earlier

2003-02-19 Thread Hiroshi Inoue
Tom Lane wrote: Hiroshi Inoue [EMAIL PROTECTED] writes: Tom Lane wrote: Hiroshi Inoue [EMAIL PROTECTED] writes: Is there a way to make our way around the pages ? If the header is corrupt, I don't think so. What I asked is how to read all other sane pages

Re: [HACKERS] A bad behavior under autocommit off mode

2003-02-20 Thread Hiroshi Inoue
Tom Lane wrote: Hiroshi Inoue [EMAIL PROTECTED] writes: Tom Lane wrote: IIRC, the SET does *not* start a transaction, Yes but doesn't autocommit-off mode mean that it implicitly begins a transaction in suitable places ? For example, 'set autocommit to off

Re: [HACKERS] A bad behavior under autocommit off mode

2003-02-20 Thread Hiroshi Inoue
Tom Lane wrote: Hiroshi Inoue [EMAIL PROTECTED] writes: Anyway should 'set autocommit to off;commit' cause a warning or an error in the first place ? IIRC, the SET does *not* start a transaction, Yes but doesn't autocommit-off mode mean that it implicitly

Re: [HACKERS] A bad behavior under autocommit off mode

2003-02-20 Thread Hiroshi Inoue
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Hiroshi Inoue [EMAIL PROTECTED] writes: There seems a bad behavior under autocommit off mode. 1) psql -c 'set autocommit to off;select 1;commit' causes a WARNING: COMMIT: no transaction in progress Surely

Re: [HACKERS] Detecting corrupted pages earlier

2003-02-18 Thread Hiroshi Inoue
Tom Lane wrote: Postgres has a bad habit of becoming very confused if the page header of a page on disk has become corrupted. In particular, bogus values in the pd_lower field tend to make it look like there are many more tuples than there really are, and of course these

Re: [HACKERS] Roadmap for FE/BE protocol redesign

2003-03-11 Thread Hiroshi Inoue
Tom Lane wrote: I think such compatibility is sufficient. We can mention in the releases notes that they should upgrade there servers before their clients. I'd be really happy if we can make that stick. There's enough work to be done here without trying to

Re: [HACKERS] Roadmap for FE/BE protocol redesign

2003-03-13 Thread Hiroshi Inoue
Dave Page wrote: It's rumoured that Hiroshi Inoue once said: Tom Lane wrote: "Dave Page" [EMAIL PROTECTED] writes: No, but with them we can avoid cluttering the wire protocol with fields for all this, and the JDBC required data. With 2 numeric

Re: [HACKERS] Roadmap for FE/BE protocol redesign

2003-03-12 Thread Hiroshi Inoue
Peter Eisentraut wrote: Dave Page writes: Well what I *really* need has been made quite clear in other posts, but, when I say resultset in the same sentence as pgAdmin, I'm referring to the ability to enter an arbitrary SQL query, have the results displayed in a

Re: [HACKERS] Roadmap for FE/BE protocol redesign

2003-03-13 Thread Hiroshi Inoue
-Original Message- From: Dave Page -Original Message- From: Hiroshi Inoue [mailto:[EMAIL PROTECTED] Sent: 13 March 2003 10:04 To: Dave Page Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [HACKERS

Re: [HACKERS] Roadmap for FE/BE protocol redesign

2003-03-13 Thread Hiroshi Inoue
Tom Lane wrote: "Dave Page" [EMAIL PROTECTED] writes: It's rumoured that Hiroshi Inoue once said: Does looking up by the catalog keys take no cost ? Obviously there is cost, but doing a lookup only on demand, has got to be cheaper in the long run than

Re: [HACKERS] A bad behavior under autocommit off mode

2003-03-20 Thread Hiroshi Inoue
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I think our SET functionality is easy to understand and use. I don't see pushing it into the client as greatly improving things, and could make things worse. If we can't get it right in the backend, how many

Re: [HACKERS] RFC: Restructuring pg_aggregate

2002-04-10 Thread Hiroshi Inoue
Tom Lane wrote: Hiroshi Inoue [EMAIL PROTECTED] writes: Tom Lane wrote: That means that a lot of low-level places *do* need to know about the dropped-column convention, else they can't make any sense of tuple layouts. Why ? As you already mentioned, there were not that many places

Re: [HACKERS] RFC: Restructuring pg_aggregate

2002-04-10 Thread Hiroshi Inoue
Bruce Momjian wrote: Hiroshi Inoue wrote: Tom Lane wrote: Hiroshi's "DROP_COLUMN_HACK" was essentially along this line, but I think he made a representational mistake by trying to change the attnums of dropped columns to be negative values. Negative attnums had 2

Re: [HACKERS] RFC: Restructuring pg_aggregate

2002-04-10 Thread Hiroshi Inoue
Bruce Momjian wrote: Hiroshi Inoue wrote: Why ? As you already mentioned, there were not that many places to be changed. Well what's changed since then ? Here is an old email from me that outlines the idea of having a physical/logical attribute numbering system

Re: [HACKERS] RFC: Restructuring pg_aggregate

2002-04-10 Thread Hiroshi Inoue
. regards, Hiroshi Inoue ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org

Re: [HACKERS] RFC: Restructuring pg_aggregate

2002-04-10 Thread Hiroshi Inoue
Bruce Momjian wrote: Hiroshi Inoue wrote: If the client has to bear the some part, isn't the invisible column approach much simpler ? I've put a pretty much time into DROP COLUMN feature but I am really disappointed to see the comments in this thread. What DROP COLUMN has brought me

Re: [HACKERS] 7.3 schedule

2002-04-11 Thread Hiroshi Inoue
literal constants involved (especially if they're not part of the WHERE clause). Saving query plans via PREPARE seems quite sufficient, and appropriate, to tackle the planner-overhead issue. Just a confirmation. Someone is working on PREPARE/EXECUTE ? What about Karel's work ? regards, Hiroshi

Re: [HACKERS] RFC: Restructuring pg_aggregate

2002-04-11 Thread Hiroshi Inoue
Bruce Momjian wrote: Hiroshi Inoue wrote: Christopher Kings-Lynne wrote: I think that is why Tom was suggesting making all the column values NULL and removing the pg_attribute row for the column. With a NULL value, it doesn't take up any room in the tuple, and with the pg_attribute

Re: [HACKERS] What's the CURRENT schema ?

2002-04-10 Thread Hiroshi Inoue
Fernando Nasser wrote: Hiroshi Inoue wrote: Fernando Nasser wrote: As most things in the SQL standard, you have to collect information from several places and add it together. Look at 4.20, 11.1 and specially at the rules for schema qualified name. Then think

Re: [HACKERS] RFC: Restructuring pg_aggregate

2002-04-11 Thread Hiroshi Inoue
a foreign key a_rel/1/3 and the second column of the relation is dropped the parameter must be changed to be a_rel/1/2. If neither foreign key stuff nor DROP COLUMN take the other into account, the consistency is easily broken. regards, Hiroshi Inoue ---(end of broadcast

Re: [HACKERS] RFC: Restructuring pg_aggregate

2002-04-14 Thread Hiroshi Inoue
is that the differene is very small. regards, Hiroshi Inoue ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Operators and schemas

2002-04-15 Thread Hiroshi Inoue
What does the current schema mean ? Or What does "local" mean ? regards, Hiroshi Inoue ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [HACKERS] timeout implementation issues

2002-04-18 Thread Hiroshi Inoue
the TODO first and put it back to the neutral position. regards, Hiroshi Inoue http://w2422.nsk.ne.jp/~inoue/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] timeout implementation issues

2002-04-18 Thread Hiroshi Inoue
s that SET commands are out of transactional control and so the word *commit SETs even after* has no meaning to me. Basically it's a user's responsisbilty to manage the errors. He only knows what's to do with the errors. regards, Hiroshi Inoue http://w2422.nsk.ne

Re: [HACKERS] timeout implementation issues

2002-04-18 Thread Hiroshi Inoue
Tom Lane wrote: Hiroshi Inoue [EMAIL PROTECTED] writes: I don't think this is *all* *should be* or *all or nothing* kind of thing. If a SET variable has its reason, it would behave in its own right. Well, we could provide some kind of escape hatch to let the behavior vary from one

Re: [HACKERS] timeout implementation issues

2002-04-18 Thread Hiroshi Inoue
Michael Loftis wrote: Hiroshi Inoue wrote: Tom Lane wrote: Hiroshi Inoue [EMAIL PROTECTED] writes: I don't think this is *all* *should be* or *all or nothing* kind of thing. If a SET variable has its reason, it would behave in its own right. Well, we could provide some kind

Re: [HACKERS] Vote on SET in aborted transaction

2002-04-24 Thread Hiroshi Inoue
s a *had better* or *convenient* kind of thing not a *no alternative* kind of thing. regards, Hiroshi Inoue http://w2422.nsk.ne.jp/~inoue/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org

Re: [HACKERS] Vote on SET in aborted transaction

2002-04-24 Thread Hiroshi Inoue
Our current behavior is 2. Please vote and I will tally the results. Is it a vote in the first place ? I will vote the current(2 + 3 + ?). regards, Hiroshi Inoue http://w2422.nsk.ne.jp/~inoue/ ---(end of broadcast)--- TIP 3: if posting

Re: [HACKERS] Vote on SET in aborted transaction

2002-04-24 Thread Hiroshi Inoue
the search_path be put back in this case ? As I mentioned already many times, it doesn't seem *should be* kind of thing. regards, Hiroshi Inoue http://w2422.nsk.ne.jp/~inoue/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go

Re: [HACKERS] Vote on SET in aborted transaction

2002-04-24 Thread Hiroshi Inoue
Jan Wieck wrote: Hiroshi Inoue wrote: Tom Lane wrote: Right offhand, I am not seeing anything here for which there's a compelling case not to roll it back on error. In fact, I have yet to hear *any* plausible example of a variable that we would really seriously want

Re: [HACKERS] Vote totals for SET in aborted transaction

2002-04-24 Thread Hiroshi Inoue
#3 #? Thomas Lockhart Hiroshi Inoue Looks like #1 is the clear winner. I voted not only ? but also 2 and 3. And haven't I asked twice or so if it's a vote ? Hiroshi Inoue http://w2422.nsk.ne.jp/~inoue/ ---(end of broadcast

Re: [HACKERS] Vote totals for SET in aborted transaction

2002-04-24 Thread Hiroshi Inoue
Bruce Momjian wrote: Hiroshi Inoue wrote: Bruce Momjian wrote: OK, the votes are in: #1 Lamar Owen Jan Wieck Tom Lane Bruce Momjian Joe Conway Curt Sampson Michael Loftis Vince

Re: [HACKERS] Vote totals for SET in aborted transaction

2002-04-24 Thread Hiroshi Inoue
are exclusive. Well, 2 says roll back only after transaction aborts, Sorry for my poor understanding. Isn't it 1 ? regards, Hiroshi Inoue http://w2422.nsk.ne.jp/~inoue/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet

Re: [HACKERS] Vote totals for SET in aborted transaction

2002-04-24 Thread Hiroshi Inoue
Bruce Momjian wrote: Hiroshi Inoue wrote: Bruce Momjian wrote: I voted not only ? but also 2 and 3. And haven't I asked twice or so if it's a vote ? Yes, it is a vote, and now that we see how everyone feels, we can decide what to do. Hiroshi, you

Re: [HACKERS] Vote on SET in aborted transaction

2002-04-24 Thread Hiroshi Inoue
Michael Loftis wrote: Hiroshi Inoue wrote: What's wrong with it ? The insert command after *rollback* would fail. It seems the right thing to me. Otherwise the insert command would try to append the data of the table t1 to itself. The insert command is for copying schema1.t1 to foo.t1

Re: [HACKERS] Vote totals for SET in aborted transaction

2002-04-24 Thread Hiroshi Inoue
Bruce Momjian wrote: Hiroshi Inoue wrote: Must I understand this from your previous posting (2 says roll back only after transaction aborts,) or original posting ? What I understood was 2 only says that SET fails between a failure and the subsequenct ROLLBACK call. Yes, 2 says

Re: [HACKERS] Vote on SET in aborted transaction

2002-04-24 Thread Hiroshi Inoue
Michael Loftis wrote: Hiroshi Inoue wrote: Where's the restriction that all objects in a schema must be created in an transaction ? Each user has his reason and would need various kind of command call sequence. What I've mainly insisted is what to do with errors is users' responsibilty

Re: [HACKERS] Vote on SET in aborted transaction

2002-04-24 Thread Hiroshi Inoue
Jan Wieck wrote: Hiroshi Inoue wrote: Sure should it! You gave an example for the need to roll back, because otherwise you would end up with an invalid search path "foo". What's wrong with it ? The insert command after *rollback* would fail

Re: [HACKERS] Vote on SET in aborted transaction

2002-04-24 Thread Hiroshi Inoue
Bruce Momjian wrote: Hiroshi Inoue wrote: Hiroshi, we need a psql solution too. People are feeding query files into psql all the time and we should have an appropriate behavior for them. What are you expecting for psql e.g. the following wrong(?) example ? [The curren schema

Re: [HACKERS] Vote on SET in aborted transaction

2002-04-24 Thread Hiroshi Inoue
and you would rather ODBC handle what to do with SETs. Not sure I like pushing that job off to the application programmer, but I think I see your point. Ahhh Hiroshi is talkign formt he aspect of ODBC? Well, thats an ODBC issue, should be handled by the ODBC driver. No. regards, Hiroshi

Re: [HACKERS] Vote on SET in aborted transaction

2002-04-24 Thread Hiroshi Inoue
Bruce Momjian wrote: Hiroshi Inoue wrote: What are you expecting for psql e.g. the following wrong(?) example ? [The curren schema is schema1] begin; create schema foo; set search_path = foo; create table t1 (); [error occurs

Re: [HACKERS] Vote on SET in aborted transaction

2002-04-24 Thread Hiroshi Inoue
schema1.t1 in case of errors. Yes, I think that is how it would behave. If you don't roll back 'set search_path', you are pointing to a non-existant schema. OK I see your standpoint. If Tom agrees with Bruce I don't object any more. regards, Hiroshi Inoue ---(end

Re: [HACKERS] [GENERAL] Using views and MS access via odbc

2002-05-01 Thread Hiroshi Inoue
* UPDATE 0 * means no tuple was updated. regards, Hiroshi Inoue http://w2422.nsk.ne.jp/~inoue/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECT

Re: [HACKERS] [GENERAL] Using views and MS access via odbc

2002-05-02 Thread Hiroshi Inoue
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED]] Hiroshi Inoue [EMAIL PROTECTED] writes: Your settings probably worked well under 7.1 but doesn't in 7.2 due to the following change in tcop/postgres.c. AFAIR, there is only a visible change of behavior for INSERT

Re: [HACKERS] [GENERAL] Using views and MS access via odbc

2002-05-03 Thread Hiroshi Inoue
-Original Message- From: Tom Lane Hiroshi Inoue [EMAIL PROTECTED] writes: Your settings probably worked well under 7.1 but doesn't in 7.2 due to the following change in tcop/postgres.c. AFAIR, there is only a visible change of behavior for INSERT/UPDATE/DELETE queries

Re: [HACKERS] [GENERAL] Using views and MS access via odbc

2002-05-04 Thread Hiroshi Inoue
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED]] "Hiroshi Inoue" [EMAIL PROTECTED] writes: If you'd not like to change the behavior, I would change it, OK ? To what? I don't want to simply undo the 7.2 change. What I'm thinking is the following makesh

Re: [HACKERS] [GENERAL] Using views and MS access via odbc

2002-05-04 Thread Hiroshi Inoue
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED]] "Hiroshi Inoue" [EMAIL PROTECTED] writes: If you'd not like to change the behavior, I would change it, OK ? To what? I don't want to simply undo the 7.2 change. What I'm thinking is the following mak

Re: [HACKERS] [GENERAL] Using views and MS access via odbc

2002-05-05 Thread Hiroshi Inoue
ordinary updatable views in 7.2. regards, Hiroshi Inoue ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Number of attributes in HeapTupleHeader

2002-05-05 Thread Hiroshi Inoue
COLUMN without touching the tuples. If the machanism is lost(I believe so) by removing t_natts, I would say good bye to PostgreSQL. regards, Hiroshi Inoue ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org

Re: [HACKERS] Number of attributes in HeapTupleHeader

2002-05-06 Thread Hiroshi Inoue
Neil Conway wrote: On Mon, 6 May 2002 08:44:27 +0900 "Hiroshi Inoue" [EMAIL PROTECTED] wrote: -Original Message- From: Manfred Koizar If there is interest in reducing on-disk tuple header size and I have not missed any strong arguments against dropping t_n

Re: [HACKERS] Number of attributes in HeapTupleHeader

2002-05-06 Thread Hiroshi Inoue
the current implementaion of ADD COLUMN (without default) together to touch tuples. regards, Hiroshi Inoue http://w2422.nsk.ne.jp/~inoue/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe

Re: [HACKERS] Queries using rules show no rows modified?

2002-05-09 Thread Hiroshi Inoue
but fixes the most siginificant case(typical updatable views). regards, Hiroshi Inoue http://w2422.nsk.ne.jp/~inoue/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] Queries using rules show no rows modified?

2002-05-09 Thread Hiroshi Inoue
Tom Lane wrote: Hiroshi Inoue [EMAIL PROTECTED] writes: Of cource it is nice to have a complete solution immediately but it doesn't seem easy. My patch is only a makeshift solution but fixes the most siginificant case(typical updatable views). I would like to devise a complete

Re: [HACKERS] Queries using rules show no rows modified?

2002-05-10 Thread Hiroshi Inoue
Jan Wieck wrote: Hiroshi Inoue wrote: Tom Lane wrote: What should the backends return for complicated rewrites ? And how should/could clients handle the results ? It doesn't seem easy to me and it seems a flaw of rule system. Honestly I don't think that the psqlodbc driver can

Re: [HACKERS] Nested transactions RFC

2002-05-12 Thread Hiroshi Inoue
direction to solve the TODO is decided. 1) without UNDO for individual tuples. 2) with UNDO for individual tuples under no overwriting smgr. 3) UNDO under overwriting smgr. regards, Hiroshi Inoue http://w2422.nsk.ne.jp/~inoue/ ---(end of

[HACKERS] What's the meaning of system column in views

2002-05-13 Thread Hiroshi Inoue
to me e.g. # create view aview as select ctid, * from a_table; ERROR: name of column "ctid" conflicts with an existing system column If there's no objection I would remove system columns from views and allow the second example. regards, Hiroshi Inoue http://w2422.nsk.ne

Re: [HACKERS] SetQuerySnapshot, once again

2002-06-18 Thread Hiroshi Inoue
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED]] Hiroshi Inoue [EMAIL PROTECTED] writes: Tom Lane wrote: Sorry, I don't understand ... Let t be a table which is defined as create table t (id serial primary key, dt text); Then is the following function *stable

Re: [HACKERS] SetQuerySnapshot, once again

2002-06-18 Thread Hiroshi Inoue
Tom Lane wrote: "Hiroshi Inoue" [EMAIL PROTECTED] writes: I already mentioned an opinion in 2001/09/08. Both the command counters and the snapshots in a function should advance except the leading SELECT statements. I do not like the idea of treating the fi

Re: [HACKERS] ODBC Driver 7.02.0001 (Win32) (Unicode mode): CRLF-LF

2002-06-24 Thread Hiroshi Inoue
2.nsk.ne.jp/~inoue/ ? regards, Hiroshi Inoue http://w2422.nsk.ne.jp/~inoue/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] ODBC Driver 7.02.0001 (Win32) (Unicode mode): CRLF-LF

2002-06-24 Thread Hiroshi Inoue
Julian Mehnle wrote: Hiroshi Inoue [EMAIL PROTECTED] wrote: Julian Mehnle [EMAIL PROTECTED] wrote: Recently I tried to use the new 7.02.0001 Win32 ODBC driver in the new (beta) Unicode mode in conjunction with MS Access 2000 and a "UNICODE" encoded database stored in a

Re: [HACKERS] ODBC Driver 7.02.0001 (Win32) (Unicode mode): CRLF-LF

2002-06-26 Thread Hiroshi Inoue
Julian Mehnle wrote: Yeah, it does *not* exhibit the faulty CRLF-LF conversion behavior. Is this a custom build of the ODBC driver done by you? Will the official driver be fixed soon? I would commit the fix to cvs this week. regards, Hiroshi Inoue http://w2422.nsk.ne.jp/~inoue

Re: [HACKERS] BETWEEN Node DROP COLUMN

2002-07-03 Thread Hiroshi Inoue
to ignore dropped columns - This is also up for grabs. As I remember, Hiroshi's drop column changed the attribute number to a special negative value, which required lots of changes to track. ??? What do you mean by *lots of* ? regards, Hiroshi Inoue http://w2422.nsk.ne.jp/~inoue

Re: [HACKERS] BETWEEN Node DROP COLUMN

2002-07-03 Thread Hiroshi Inoue
Bruce Momjian wrote: Hiroshi Inoue wrote: As I remember, Hiroshi's drop column changed the attribute number to a special negative value, which required lots of changes to track. ??? What do you mean by *lots of* ? Yes, please remind me. Was your solution renumbering the attno

Re: [HACKERS] BETWEEN Node DROP COLUMN

2002-07-03 Thread Hiroshi Inoue
Bruce Momjian wrote: Hiroshi Inoue wrote: Bruce Momjian wrote: Hiroshi Inoue wrote: As I remember, Hiroshi's drop column changed the attribute number to a special negative value, which required lots of changes to track. ??? What do you mean by *lots of* ? Yes

Re: [HACKERS] BETWEEN Node DROP COLUMN

2002-07-03 Thread Hiroshi Inoue
that we can use. Apart from the DropColumn function itself, what other changes did you make? Did you have modifications for '*' expansion in the parser, etc.? Don't mind my posting. I'm only correcting a misunderstanding for my work. regards, Hiroshi Inoue http://w2422.nsk.ne.jp/~inoue

Re: [HACKERS] BETWEEN Node DROP COLUMN

2002-07-04 Thread Hiroshi Inoue
Tom Lane wrote: Hiroshi Inoue [EMAIL PROTECTED] writes: I used the following macro in my trial implementation. #define COLUMN_IS_DROPPED(attribute) ((attribute)-attnum = DROP_COLUMN_OFFSET) The places where the macro was put are exactly the places where attisdropped must be checked

Re: [HACKERS] BETWEEN Node DROP COLUMN

2002-07-04 Thread Hiroshi Inoue
Tom Lane wrote: Hiroshi Inoue [EMAIL PROTECTED] writes: Tom Lane wrote: Actually, your trial required column dropped-ness to be checked in many more places than the proposed approach does. Have you ever really checked my trial implementation ? Well, I've certainly stumbled over

Re: [HACKERS] BETWEEN Node DROP COLUMN

2002-07-04 Thread Hiroshi Inoue
. regards, Hiroshi Inoue http://w2422.nsk.ne.jp/~inoue/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [HACKERS] BETWEEN Node DROP COLUMN

2002-07-06 Thread Hiroshi Inoue
level code, and that he hasn't found all of it. Please don't propagate an unfair valuation without any verification. regards, Hiroshi Inoue ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscr

Re: [HACKERS] DROP COLUMN

2002-07-16 Thread Hiroshi Inoue
would catch dropped columns too, but it causes other problems that are harder to fix so we _dropped_ the idea. What does this mean ? BTW would we do nothing for clients after all ? regards, Hiroshi Inoue ---(end of broadcast)--- TIP 3

Re: [HACKERS] DROP COLUMN

2002-07-16 Thread Hiroshi Inoue
Bruce Momjian wrote: Hiroshi Inoue wrote: Makes sense. Of course, we could make a syscache that didn't return system columns either. Actually, the original argument for negative attno's for dropped columns was exactly for this case, that the system column check would catch

Re: [HACKERS] DROP COLUMN

2002-07-16 Thread Hiroshi Inoue
Bruce Momjian wrote: Hiroshi Inoue wrote: Bruce Momjian wrote: Hiroshi Inoue wrote: BTW would we do nothing for clients after all ? Clients will now need to check that dropped flag. Clients would have to check the flag everywhere pg_attribute appears. Why should

Re: [HACKERS] DROP COLUMN

2002-07-16 Thread Hiroshi Inoue
in attnums ? And I don't object to the attisdropped flag implemetation as long as it doesn't scatter the attisdropped test around client applications. Why would you like to do nothing for clients ? regards, Hiroshi Inoue http://w2422.nsk.ne.jp/~inoue/ ---(end

Re: [HACKERS] DROP COLUMN

2002-07-16 Thread Hiroshi Inoue
Tom Lane wrote: Hiroshi Inoue [EMAIL PROTECTED] writes: Have I ever mentioned that negative attno's is better than the attisdropped flag implemetation in the handling of gaps in attnums ? How so? I don't see any improvement ... Sorry please ignore my above words if it has no meanig

Re: [HACKERS] DROP COLUMN

2002-07-17 Thread Hiroshi Inoue
Hannu Krosing wrote: On Wed, 2002-07-17 at 09:11, Hiroshi Inoue wrote: Bruce Momjian wrote: From my perspective, when client coders like Dave Page and others say they would prefer the flag to the negative attno's, I don't have to understand. I just take their word for it. do

Re: [HACKERS] DROP COLUMN

2002-07-17 Thread Hiroshi Inoue
I sent a draft by mistake, sorry. Hannu Krosing wrote: On Wed, 2002-07-17 at 09:11, Hiroshi Inoue wrote: Bruce Momjian wrote: From my perspective, when client coders like Dave Page and others say they would prefer the flag to the negative attno's, I don't have to understand. I

Re: [HACKERS] DROP COLUMN

2002-07-17 Thread Hiroshi Inoue
attnums in the same way ? regards, Hiroshi Inoue http://w2422.nsk.ne.jp/~inoue/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can

Re: [HACKERS] pg_inherits: not found, but visible

2001-03-20 Thread Hiroshi Inoue
= 18720 2) relfilenode(==oid) = 16567; and I could find a $PGDATA/base/18720/16567 file. Could you find such a file ? regards, Hiroshi Inoue ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl

Re: [HACKERS] pg_inherits: not found, but visible

2001-03-20 Thread Hiroshi Inoue
Joel Burton wrote: On Wed, 21 Mar 2001, Hiroshi Inoue wrote: Joel Burton wrote: Postmaster crashed on me, and on restart, pg_inherits cannot be found. I can see it in pg_class (and it shows up w/ \dS), but any attempt to modify anything fails with "pg_inherits: No such

Re: [HACKERS] pgindent run?

2001-03-22 Thread Hiroshi Inoue
* 2) we are in autocommit off state and the statement isn't of type * OTHER. */ regards, Hiroshi Inoue ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddress

Re: [HACKERS] Re: [SQL] possible row locking bug in 7.0.3 7.1

2001-03-27 Thread Hiroshi Inoue
. regards, Hiroshi Inoue ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly

RE: AW: [HACKERS] Re: [SQL] possible row locking bug in 7.0.3 7.1

2001-03-30 Thread Hiroshi Inoue
es a common snapshot for a TX. Each query in READ COMMITTED isolation level uses its own snapshot. It seems the only difference between SERIALZABLE and READ COMMITTED. But there's a sort of SERIALIZABLE world inside functions even under READ COMMITTED mode. regards, Hiroshi Inoue ---

Re: [HACKERS] ALTER TABLE MODIFY COLUMN

2001-04-12 Thread Hiroshi Inoue
to replace existent relation files safely. We could avoid running VACUUM, multiple version of tuples in a file etc ... regards, Hiroshi Inoue ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail

[HACKERS] 7.1 startup recovery failure

2001-04-26 Thread Hiroshi Inoue
Hi, There's a report of startup recovery failure in Japan. Redo done but ... Unfortunately I have no time today. regards, Hiroshi Inoue KAMI wrote: DEBUG: database system shutdown was interrupted at 2001-04-26 22:15:00 JST DEBUG: CheckPoint record at (1, 3923829232) DEBUG: Redo record

Re: [HACKERS] 7.1 startup recovery failure

2001-04-29 Thread Hiroshi Inoue
w in Japan. Probably we couldn't expect too much of him. regards, Hiroshi Inoue ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl

  1   2   3   4   5   >