No title
Hi,
This is the first posting to the community of the WIP patch for the
Updatable Cursor implementation.
I want to confirm that the community is satisfied that the effort to date is
in a suitable direction and to get comments on the development to date.
The patch is in the following state:
The grammar definition is complete and 'yacc'ed to produce gram.y.c.
The functions transformUpdateStmt and transformDeleteStmt have been updated
to process the cursor name and obtain the related portal.
The change to save the current tuple id (ctid) into the portal, related to
the Fetch command has been done.
The ctids relating to the Update/Delete statements' TidScan are being
extracted to be saved in the executor.
The parts in progress are to complete the saving of the ctids from the
TidScan into a list stored in a file, plus related searching the list for an
individual ctid obtained from the Update/Delete statements.
Unstarted as yet:
1) Correctly process, in the database, the Delete / Update of the
tuple from the cursor.
2) To enable the cursor name to be defined as a parameter in a
PREPARE statement and provided as part if an EXECUTE statement.
The community may wish to comment on the following issue:
1) At present the file that will contain the list of ctids is going into
a new directory called pg_ctids, analogous to pg_twophase, and also stored
in the pg_data directory.
Regards,
John Bartlett
This is an email from Fujitsu Australia Software Technology Pty Ltd, ABN 27 003 693 481. It is confidential to the ordinary user of the email address to which it was addressed and may contain copyright and/or legally privileged information. No one else may read, print, store, copy or forward all or any of it or its attachments. If you receive this email in error, please return to sender. Thank you.
If you do not wish to receive commercial email messages from Fujitsu Australia Software Technology Pty Ltd, please email unsubscribe@fast.fujitsu.com.au
Attachments:
270207_updatable_cursor.diffapplication/octet-stream; name=270207_updatable_cursor.diffDownload
diff -rc head_260207/src/backend/commands/portalcmds.c head_260207_jb/src/backend/commands/portalcmds.c
*** head_260207/src/backend/commands/portalcmds.c 2007-02-26 17:12:37.000000000 +1100
--- head_260207_jb/src/backend/commands/portalcmds.c 2007-02-26 16:26:44.000000000 +1100
***************
*** 90,99 ****
(errcode(ERRCODE_INVALID_CURSOR_DEFINITION),
errmsg("DECLARE CURSOR cannot specify INTO")));
if (query->rowMarks != NIL)
! ereport(ERROR,
! (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
! errmsg("DECLARE CURSOR ... FOR UPDATE/SHARE is not supported"),
! errdetail("Cursors must be READ ONLY.")));
plan = planner(query, true, stmt->options, params);
--- 90,100 ----
(errcode(ERRCODE_INVALID_CURSOR_DEFINITION),
errmsg("DECLARE CURSOR cannot specify INTO")));
if (query->rowMarks != NIL)
! if (query->forUpdate == FALSE)
! ereport(ERROR,
! (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
! errmsg("DECLARE CURSOR ... FOR SHARE is not supported"),
! errdetail("Cursors must not be FOR SHARE.")));
plan = planner(query, true, stmt->options, params);
/*-------------------------------------------------
*
* ctidListStore.c
* Contains the processing relating to the storage of the list of ctids
* required for Updatable Cursor.
*
* The details to be handled here include:
*
* use of shared memory to hold basic list
* format and use of file for permanent storage of list
* functions to access and search the shared memory, ie use the list
* functions to access and build the list
* functions to initialise and empty the list
* functions to initialise and remove the file associated with the list
* functions to populate shared memory from existing ctid files during
* database startup.
*
* INTERFACE ROUTINES
*
* saveCtids(ItemPointer ctid)
*/
#include "backend/executor/ctidListStore.h"
/*
* Directory where CTID list files reside within PGDATA
*/
#define CTID_DIR "pg_ctids"
static List *ctidList; /* list of ctids for updatable cursor */
static void RegisterCtidRecord();
static void ReadCtidFile();
static void ProcessCtidRecords();
int max_ctids_in_list = 1000; /* This is for performance reasons */
typedef struct CtidData
{
/*
* Number of Ctid records in the list
*/
int CtidCount;
ItemPointer ctidArray[1]; /* VARIABLE LENGTH ARRAY */
} CtidData; /* VARIABLE LENGTH STRUCT */
static void CtidShmemSize()
{
Size size;
/* Need the fixed struct and the ctid */
size = offsetof(CtidData, ctidArray);
size = add_size(size, sizeof(ItemPointer));
size = MAXALIGN(size);
return size;
}
static void CtidShmemInit()
{
bool found;
CtidState = ShmemInitStruct("Current Tuple Id Table",
CtidShmemSize(),
&found);
}
/************************************************************************/
/* State file support */
/************************************************************************/
#define CtidListFilePath(path, ) \
snprintf(path, MAXPGPATH, CTIDLIST_DIR "/%08X", xid)
/*
* CtidList state file format:
*
* 1. CtidListFileHeader
* 5. CtidRecordOnDisk
* 6. ...
* 7. CtidRecordOnDisk (end sentinel, rmid == CTIDLIST_RM_END_ID)
* 8. CRC32
*
* Each segment except the final CRC32 is MAXALIGN'd.
*/
/*
* Header for a CtidList file
*/
#define CTIDLIST_MAGIC ???????? /* format identifier HOW IS THIS DEFINED */
typedef struct CtidListFileHeader
{
uint32 magic; /* format identifier */
uint32 total_len; /* actual file length */
TransactionId xid; /* original transaction XID */
Oid database; /* OID of database it was in */
Oid owner; /* user running the transaction */
char gid[GIDSIZE]; /* GID for transaction */
} CtidListFileHeader;
/*
* Header for each record in a state file
*
* NOTE: len counts only the rmgr data, not the TwoPhaseRecordOnDisk header.
* The rmgr data will be stored starting on a MAXALIGN boundary.
*/
typedef struct CtidRecordOnDisk
{
uint32 len; /* length of rmgr data */
CtidListRmgrId rmid; /* resource manager for this record */
uint16 info; /* flag bits for use by rmgr */
} CtidRecordOnDisk;
/* WILL CTID LIST BE WRITTEN TO WAL???
* During prepare, the state file is assembled in memory before writing it
* to WAL and the actual state file. We use a chain of XLogRecData blocks
* so that we will be able to pass the state file contents directly to
* XLogInsert.
*/
static struct xllist
{
XLogRecData *head; /* first data block in the chain */
XLogRecData *tail; /* last block in chain */
uint32 bytes_free; /* free bytes left in tail block */
uint32 total_len; /* total data bytes in chain */
} records;
static void StartCtidPrepare()
{
}
static void EndCtidPrepare()
{
}
static void RemoveCtidFile()
{
}
static void
saveCtid(ItemPointer ctid)
{
if (ctidList != NIL)
lappend(ctidList,ctid);
}
static ItemPointer findCtidInList(ItemPointer ctid)
{
if (ctidList == NILL)
return;
while(
}
/*
* ctidListStore.h
*
* Header file to expose the interface for ctid shared memory and file
* processing
*/
static void saveCtid(ItemPointer ctid);
static ItemPointer findCtidInList(ItemPointer ctid);
static void CtidShmemSize();
static void CtidShmemInit();
static void StartCtidPrepare();
static void EndCtidPrepare();
static void RemoveCtidFile();
diff -rc head_260207/src/backend/executor/execMain.c head_260207_jb/src/backend/executor/execMain.c
*** head_260207/src/backend/executor/execMain.c 2007-02-26 17:21:03.000000000 +1100
--- head_260207_jb/src/backend/executor/execMain.c 2007-02-26 16:29:08.000000000 +1100
***************
*** 41,46 ****
--- 41,47 ----
#include "catalog/toasting.h"
#include "commands/tablespace.h"
#include "commands/trigger.h"
+ #include "executor/ctidListStore.h"
#include "executor/execdebug.h"
#include "executor/instrument.h"
#include "executor/nodeSubplan.h"
***************
*** 70,76 ****
List *rangeTable,
CmdType operation,
bool doInstrument);
! static TupleTableSlot *ExecutePlan(EState *estate, PlanState *planstate,
CmdType operation,
long numberTuples,
ScanDirection direction,
--- 71,77 ----
List *rangeTable,
CmdType operation,
bool doInstrument);
! static TupleTableSlot *ExecutePlan(EState *estate, QueryDesc *queryDesc,
CmdType operation,
long numberTuples,
ScanDirection direction,
***************
*** 240,246 ****
result = NULL;
else
result = ExecutePlan(estate,
! queryDesc->planstate,
operation,
count,
direction,
--- 241,247 ----
result = NULL;
else
result = ExecutePlan(estate,
! queryDesc,
operation,
count,
direction,
***************
*** 1009,1022 ****
*/
static TupleTableSlot *
ExecutePlan(EState *estate,
! PlanState *planstate,
CmdType operation,
long numberTuples,
ScanDirection direction,
DestReceiver *dest)
{
JunkFilter *junkfilter;
TupleTableSlot *planSlot;
TupleTableSlot *slot;
ItemPointer tupleid = NULL;
ItemPointerData tuple_ctid;
--- 1010,1025 ----
*/
static TupleTableSlot *
ExecutePlan(EState *estate,
! QueryDesc *queryDesc,
CmdType operation,
long numberTuples,
ScanDirection direction,
DestReceiver *dest)
{
JunkFilter *junkfilter;
+ PlanState *planstate = queryDesc->planstate;
TupleTableSlot *planSlot;
+ TupleTaplanstatebleSlot *planSlot;
TupleTableSlot *slot;
ItemPointer tupleid = NULL;
ItemPointerData tuple_ctid;
***************
*** 1103,1110 ****
--- 1106,1116 ----
/*
* extract the 'ctid' junk attribute.
+ * The third condition here relates to updatable cursor, when
+ * the ctid must always be extracted.
*/
if (operation == CMD_UPDATE || operation == CMD_DELETE)
+ queryDesc->parsetree->portal != NULL))
{
datum = ExecGetJunkAttribute(slot, junkfilter->jf_junkAttNo,
&isNull);
***************
*** 1115,1120 ****
--- 1121,1154 ----
tupleid = (ItemPointer) DatumGetPointer(datum);
tuple_ctid = *tupleid; /* make sure we don't free the ctid!! */
tupleid = &tuple_ctid;
+
+ /*
+ * Save the ctid in portal for updatable cursor during Fetch
+ * request
+ */
+ if (((FetchStmt *)queryDesc->parsetree->utilityStmt)->type == T_FetchStmt)
+ {
+ /*
+ * Save the ctid and tuple in the portal for
+ * updatable cursor during a Fetch request.
+ */
+ queryDesc->parsetree->portal->ctid = tupleid;
+ queryDesc->parsetree->portal->tuple = slot;
+ }
+ else if ((queryDesc->parsetree->commandType == CMD_UPDATE ||
+ queryDesc->parsetree->commandType == CMD_DELETE) &&
+ queryDesc->parsetree->portal != NULL &&
+ NodeTag(planstate) == TidScanState &&
+ ctidList == NULL)
+ {
+ /*
+ * Update or Delete statement with updatable cursor
+ * executing the TidScan node for the first time in
+ * this query so save the tupleid into a hash table
+ * and store to disk.
+ */
+ saveCtid(tupleid);
+ }
}
/*
diff -rc head_260207/src/backend/optimizer/path/tidpath.c head_260207_jb/src/backend/optimizer/path/tidpath.c
*** head_260207/src/backend/optimizer/path/tidpath.c 2007-02-26 15:12:00.000000000 +1100
--- head_260207_jb/src/backend/optimizer/path/tidpath.c 2007-02-26 16:30:47.000000000 +1100
***************
*** 41,46 ****
--- 41,47 ----
static bool IsTidEqualClause(OpExpr *node, int varno);
static bool IsTidEqualAnyClause(ScalarArrayOpExpr *node, int varno);
+ /* static List *build_tidqual(); */
static List *TidQualFromExpr(Node *expr, int varno);
static List *TidQualFromRestrictinfo(List *restrictinfo, int varno);
***************
*** 140,145 ****
--- 141,192 ----
return false;
}
+ /*
+ * build_tid_qual
+ *
+ * Create a tid qual to represent CTID = ANY and insert it into the tidqual
+ * list to be returned. As this tid qual is required only to force a TidScan to
+ * occur, it is only necessary to populate those fields required to satisfy
+ * the conditions required to force a TidScan path to be created in the plan.
+ * CTID is not a string it is data stored in a tuple. Need to obtain it from
+ * somewhere for use here...
+ *
+ * This function has been commented out as it may not be needed to implement updatable
+ * cursor functionality.
+ *
+
+ static List *
+ build_tidqual()
+ {
+ List *qualList;
+ ScalarArrayOpExpr *qual;
+ Var *arg1;
+ Node *arg2;
+
+ qual->xpr = ;
+ qual->opno = TIDEqualOperator;
+ qual->useOr = TRUE;
+
+ * Define arguments 1 and 2. arg1 is a Var, arg2 is a const.
+ * varattno is just assigned the value here to satisfy tidqual conditions
+ * It means nothing outside this area.
+ arg1->varattno = SelfItemPointerAttributeNumber;
+ arg1->vartype = TIDOID;
+ arg1->varlevelsup = 0;
+ arg1->xpr =
+ arg1->vartypmod =
+ arg1->varnoold =
+ arg1->varoattno =
+
+ * Add first and second arguments into argument list
+
+ qual->args = lappend(qual->args, arg1);
+ qual->args = lappend(qual->args, arg2);
+
+ qualList = lappend(qualList, qual);
+ return qualList;
+ }
+ */
/*
* Extract a set of CTID conditions from the given qual expression
***************
*** 239,246 ****
{
List *tidquals;
! tidquals = TidQualFromRestrictinfo(rel->baserestrictinfo, rel->relid);
! if (tidquals)
! add_path(rel, (Path *) create_tidscan_path(root, rel, tidquals));
}
--- 286,307 ----
{
List *tidquals;
! if (root->parse->portal == NULL)
! {
! tidquals = TidQualFromRestrictinfo(rel->baserestrictinfo, rel->relid);
! if (tidquals)
! add_path(rel, (Path *) create_tidscan_path(root, rel, tidquals));
! }
! else
! {
! /*
! * Updatable cursor case: According to the Executor, tid quals are
! * not required for a TidScan to be processed. So pass tidquals of NULL
! */
!
! /* tidquals = build_tidqual(); may not be needed */
! if (tidquals)
! add_path(rel, (Path *) create_tidscan_path(root, rel, NULL));
! }
}
diff -rc head_260207/src/backend/parser/analyze.c head_260207_jb/src/backend/parser/analyze.c
*** head_260207/src/backend/parser/analyze.c 2007-02-26 15:01:03.000000000 +1100
--- head_260207_jb/src/backend/parser/analyze.c 2007-02-26 16:36:20.000000000 +1100
***************
*** 508,514 ****
*/
transformFromClause(pstate, stmt->usingClause);
! qual = transformWhereClause(pstate, stmt->whereClause, "WHERE");
qry->returningList = transformReturningList(pstate, stmt->returningList);
--- 508,536 ----
*/
transformFromClause(pstate, stmt->usingClause);
! if (stmt->cursorName == NULL)
! {
! /* Only transform WHERE clause if not a WHERE CURRENT OF clause */
! qual = transformWhereClause(pstate, stmt->whereClause, "WHERE");
! }
! else
! {
! /*
! * In WHERE CURRENT OF clause obtain Portal from cursor name and save in
! * Query structure. The test condition below ensures that a combined WHERE
! * and WHERE CURRENT OF clause is not possible in a single query.
! */
! if (stmt->whereClause != NULL)
! ereport(ERROR,
! (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
! errmsg("Cannot have WHERE and WHERE CURRENT OF in same query"),
! errdetail("Only WHERE or WHERE CURRENT OF may be used in query"));
! qry->portal = GetPortalByName(stmt->cursorName);
! }
!
! qry->returningList = transformReturningList(pstate, stmt->returningList);
! qry->portal = GetPortalByName(stmt->cursorName);
! }
qry->returningList = transformReturningList(pstate, stmt->returningList);
***************
*** 2836,2841 ****
--- 2858,2864 ----
transformUpdateStmt(ParseState *pstate, UpdateStmt *stmt)
{
Query *qry = makeNode(Query);
+ Portal *portal;
Node *qual;
ListCell *origTargetList;
ListCell *tl;
***************
*** 2855,2862 ****
transformFromClause(pstate, stmt->fromClause);
qry->targetList = transformTargetList(pstate, stmt->targetList);
! qual = transformWhereClause(pstate, stmt->whereClause, "WHERE");
qry->returningList = transformReturningList(pstate, stmt->returningList);
--- 2878,2907 ----
transformFromClause(pstate, stmt->fromClause);
qry->targetList = transformTargetList(pstate, stmt->targetList);
+
+ if (stmt->cursorName == NULL)
+ {
+ /*
+ * Only call if it is not a WHERE CURRENT OF clause
+ */
+ qual = transformWhereClause(pstate, stmt->whereClause, "WHERE");
+ }
+ else
+ {
+ /*
+ * In WHERE CURRENT OF cursor name, get Portal from cursor name
+ * and save in Query structure. The test condition below ensures that
+ * a combined WHERE and WHERE CURRENT OF clause is not possible
+ * in a single query.
+ */
! if (stmt->whereClause != NULL)
! ereport(ERROR,
! (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
! errmsg("Cannot have WHERE and WHERE CURRENT OF in same query"),
! errdetail("Only WHERE or WHERE CURRENT OF may be used in query"));
! qry->portal = GetPortalByName(stmt->cursorName);
! }
qry->returningList = transformReturningList(pstate, stmt->returningList);
diff -rc head_260207/src/backend/parser/gram.y head_260207_jb/src/backend/parser/gram.y
*** head_260207/src/backend/parser/gram.y 2007-02-26 15:05:24.000000000 +1100
--- head_260207_jb/src/backend/parser/gram.y 2007-02-26 16:47:59.000000000 +1100
***************
*** 249,255 ****
prep_type_clause
execute_param_clause using_clause returning_clause
! %type <range> OptTempTableName
%type <into> into_clause create_as_target
%type <defelt> createfunc_opt_item common_func_opt_item
--- 249,255 ----
prep_type_clause
execute_param_clause using_clause returning_clause
! %type <range> OptTempTableName
%type <into> into_clause create_as_target
%type <defelt> createfunc_opt_item common_func_opt_item
***************
*** 375,382 ****
CHARACTER CHARACTERISTICS CHECK CHECKPOINT CLASS CLOSE
CLUSTER COALESCE COLLATE COLUMN COMMENT COMMIT
COMMITTED CONCURRENTLY CONNECTION CONSTRAINT CONSTRAINTS
CONTENT_P CONVERSION_P CONVERT COPY COST CREATE CREATEDB
- CREATEROLE CREATEUSER CROSS CSV CURRENT_DATE CURRENT_ROLE CURRENT_TIME
CURRENT_TIMESTAMP CURRENT_USER CURSOR CYCLE
DATABASE DAY_P DEALLOCATE DEC DECIMAL_P DECLARE DEFAULT DEFAULTS
--- 375,382 ----
CHARACTER CHARACTERISTICS CHECK CHECKPOINT CLASS CLOSE
CLUSTER COALESCE COLLATE COLUMN COMMENT COMMIT
COMMITTED CONCURRENTLY CONNECTION CONSTRAINT CONSTRAINTS
+ CREATEROLE CREATEUSER CROSS CSV CURRENT CURRENT_DATE CURRENT_ROLE CURRENT_TIME
CONTENT_P CONVERSION_P CONVERT COPY COST CREATE CREATEDB
CURRENT_TIMESTAMP CURRENT_USER CURSOR CYCLE
DATABASE DAY_P DEALLOCATE DEC DECIMAL_P DECLARE DEFAULT DEFAULTS
***************
*** 5584,5590 ****
DeleteStmt *n = makeNode(DeleteStmt);
n->relation = $3;
n->usingClause = $4;
! n->whereClause = $5;
n->returningList = $6;
$$ = (Node *)n;
}
--- 5584,5593 ----
DeleteStmt *n = makeNode(DeleteStmt);
n->relation = $3;
n->usingClause = $4;
! if ( (Node *)$5->type == T_A_Expr )
! n->whereClause = $5;
! else
! n->cursorName = $5;
n->returningList = $6;
$$ = (Node *)n;
}
***************
*** 5642,5648 ****
n->relation = $2;
n->targetList = $4;
n->fromClause = $5;
! n->whereClause = $6;
n->returningList = $7;
$$ = (Node *)n;
}
--- 5645,5654 ----
n->relation = $2;
n->targetList = $4;
n->fromClause = $5;
! if ( (Node *)$6->type == T_A_Expr )
! n->whereClause = $6;
! else
! n->cursorName = $6;
n->returningList = $7;
$$ = (Node *)n;
}
***************
*** 5709,5715 ****
| set_target_list ',' set_target { $$ = lappend($1,$3); }
;
-
/*****************************************************************************
*
* QUERY:
--- 5715,5720 ----
***************
*** 6440,6445 ****
--- 6445,6451 ----
where_clause:
WHERE a_expr { $$ = $2; }
+ | WHERE CURRENT OF name {$$ = $4; }
| /*EMPTY*/ { $$ = NULL; }
;
***************
*** 8996,9001 ****
--- 9002,9008 ----
| COLUMN
| CONSTRAINT
| CREATE
+ | CURRENT
| CURRENT_DATE
| CURRENT_ROLE
| CURRENT_TIME
diff -rc head_260207/src/backend/parser/keywords.c head_260207_jb/src/backend/parser/keywords.c
*** head_260207/src/backend/parser/keywords.c 2007-02-26 15:05:35.000000000 +1100
--- head_260207_jb/src/backend/parser/keywords.c 2007-02-26 16:39:02.000000000 +1100
***************
*** 100,105 ****
--- 100,106 ----
{"createuser", CREATEUSER},
{"cross", CROSS},
{"csv", CSV},
+ {"current", CURRENT},
{"current_date", CURRENT_DATE},
{"current_role", CURRENT_ROLE},
{"current_time", CURRENT_TIME},
diff -rc head_260207/src/include/executor/execdesc.h head_260207_jb/src/include/executor/execdesc.h
*** head_260207/src/include/executor/execdesc.h 2007-02-26 15:05:14.000000000 +1100
--- head_260207_jb/src/include/executor/execdesc.h 2007-02-26 17:18:30.000000000 +1100
***************
*** 47,52 ****
--- 47,56 ----
TupleDesc tupDesc; /* descriptor for result tuples */
EState *estate; /* executor's query-wide state */
PlanState *planstate; /* tree of per-plan-node state */
+ /* These fields are set by ExecutorRun ??? */
+ TupleId tupleId; /* Tuple id retrieved on cursor FETCH */
+ TupleTableSlot tuple; /* Tuple relating to tuple id */
+ RelationId relationId; /* Relation Id retrieved on cursor FETCH */
} QueryDesc;
/* in pquery.c */
diff -rc head_260207/src/include/nodes/parsenodes.h head_260207_jb/src/include/nodes/parsenodes.h
*** head_260207/src/include/nodes/parsenodes.h 2007-02-26 15:06:09.000000000 +1100
--- head_260207_jb/src/include/nodes/parsenodes.h 2007-02-26 17:13:08.000000000 +1100
***************
*** 109,114 ****
--- 109,115 ----
List *rtable; /* list of range table entries */
FromExpr *jointree; /* table join tree (FROM and WHERE clauses) */
+ Portal *portal; /* Portal relating to updatable cursor */
List *targetList; /* target list (of TargetEntry) */
***************
*** 685,690 ****
--- 686,692 ----
RangeVar *relation; /* relation to delete from */
List *usingClause; /* optional using clause for more tables */
Node *whereClause; /* qualifications */
+ char *cursorName; /* Cursor name in WHERE CURRENT OF */
List *returningList; /* list of expressions to return */
} DeleteStmt;
***************
*** 698,703 ****
--- 700,706 ----
RangeVar *relation; /* relation to update */
List *targetList; /* the target list (of ResTarget) */
Node *whereClause; /* qualifications */
+ char *cursorName; /* Cursor name in WHERE CURRENT OF */
List *fromClause; /* optional from clause for more tables */
List *returningList; /* list of expressions to return */
} UpdateStmt;
diff -rc head_260207/src/include/utils/portal.h head_260207_jb/src/include/utils/portal.h
*** head_260207/src/include/utils/portal.h 2007-02-26 15:06:20.000000000 +1100
--- head_260207_jb/src/include/utils/portal.h 2007-02-26 17:16:23.000000000 +1100
***************
*** 161,166 ****
--- 161,172 ----
MemoryContext holdContext; /* memory containing holdStore */
/*
+ * Updatable Cursor change. Here the current tuple id (ctid) is
+ * stored.
+ */
+ ItemPointer ctid; /* updatable cursor current tuple id */
+ TupleTableSlot tuple; /* tuple related to ctid */
+ /*
* atStart, atEnd and portalPos indicate the current cursor position.
* portalPos is zero before the first row, N after fetching N'th row of
* query. After we run off the end, portalPos = # of rows in query, and
John Bartlett wrote:
The community may wish to comment on the following issue:
1) At present the file that will contain the list of ctids is going into
a new directory called pg_ctids, analogous to pg_twophase, and also stored
in the pg_data directory.
I don't understand this. What's stored in the file and why? If they're
only needed within the transaction, surely a temp file would be more
appropriate?
The new ctidListStore.c file in the patch is not in a valid diff-format.
I also noticed that you've moved the line beginning with "CREATE_ROLE"
in gram.y so that it's not in alphabetical order anymore.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
FYI, I am not going to be comfortable accepting a final patch that
contains this email signature:
This is an email from Fujitsu Australia Software Technology Pty Ltd, ABN
27 003 693 481. It is confidential to the ordinary user of the email
address to which it was addressed and may contain copyright and/or
---------------------
legally privileged information. No one else may read, print, store, copy
or forward all or any of it or its attachments. If you receive this
email in error, please return to s ender. Thank you.
unless you provide additional details on your contribution of this code
under a BSD license.
---------------------------------------------------------------------------
John Bartlett wrote:
Hi,
This is the first posting to the community of the WIP patch for the
Updatable Cursor implementation.I want to confirm that the community is satisfied that the effort to date is
in a suitable direction and to get comments on the development to date.The patch is in the following state:
The grammar definition is complete and 'yacc'ed to produce gram.y.c.
The functions transformUpdateStmt and transformDeleteStmt have been updated
to process the cursor name and obtain the related portal.The change to save the current tuple id (ctid) into the portal, related to
the Fetch command has been done.The ctids relating to the Update/Delete statements' TidScan are being
extracted to be saved in the executor.The parts in progress are to complete the saving of the ctids from the
TidScan into a list stored in a file, plus related searching the list for an
individual ctid obtained from the Update/Delete statements.Unstarted as yet:
1) Correctly process, in the database, the Delete / Update of the
tuple from the cursor.2) To enable the cursor name to be defined as a parameter in a
PREPARE statement and provided as part if an EXECUTE statement.The community may wish to comment on the following issue:
1) At present the file that will contain the list of ctids is going into
a new directory called pg_ctids, analogous to pg_twophase, and also stored
in the pg_data directory.Regards,
John BartlettThis is an email from Fujitsu Australia Software Technology Pty Ltd, ABN 27 003 693 481. It is confidential to the ordinary user of the email address to which it was addressed and may contain copyright and/or legally privileged information. No one else may read, print, store, copy or forward all or any of it or its attachments. If you receive this email in error, please return to sender. Thank you.
If you do not wish to receive commercial email messages from Fujitsu Australia Software Technology Pty Ltd, please email unsubscribe@fast.fujitsu.com.au
[ Attachment, skipping... ]
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Import Notes
Reply to msg id not found: UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAw1P36NVXkuUGCDGiycCfMKAAAAQAAAAzGBOD9p2p02OTiqRatfOFQEAAAAA@fast.fujitsu.com.a | Resolved by subject fallback
Bruce Momjian wrote:
FYI, I am not going to be comfortable accepting a final patch that
contains this email signature:This is an email from Fujitsu Australia Software Technology Pty Ltd, ABN
27 003 693 481. It is confidential to the ordinary user of the email
address to which it was addressed and may contain copyright and/or
---------------------
legally privileged information. No one else may read, print, store, copy
or forward all or any of it or its attachments. If you receive this
email in error, please return to s ender. Thank you.unless you provide additional details on your contribution of this code
under a BSD license.
Gonna have to concur with that. Not that the sig is legally binding
anyway, we do need to have a disclaimer in the email stating that you
are assigning to PGDG>
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
On Tue, 2007-02-27 at 14:52 -0800, Joshua D. Drake wrote:
Gonna have to concur with that. Not that the sig is legally binding
anyway, we do need to have a disclaimer in the email stating that you
are assigning to PGDG
I think it's pretty silly to start caring about this now. Do you think
that in the absence of any signature/disclaimer attached to a patch,
then the copyright for the change is "implicitly" assigned to PGDG? (I'm
not a lawyer, but I believe that's not the case.)
-Neil
Neil Conway wrote:
On Tue, 2007-02-27 at 14:52 -0800, Joshua D. Drake wrote:
Gonna have to concur with that. Not that the sig is legally binding
anyway, we do need to have a disclaimer in the email stating that you
are assigning to PGDGI think it's pretty silly to start caring about this now. Do you think
that in the absence of any signature/disclaimer attached to a patch,
then the copyright for the change is "implicitly" assigned to PGDG? (I'm
not a lawyer, but I believe that's not the case.)
I think the issue is _explicit_ vs _implicit_. I think the email
signature was too explicit.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Neil Conway wrote:
On Tue, 2007-02-27 at 14:52 -0800, Joshua D. Drake wrote:
Gonna have to concur with that. Not that the sig is legally binding
anyway, we do need to have a disclaimer in the email stating that you
are assigning to PGDGI think it's pretty silly to start caring about this now. Do you think
that in the absence of any signature/disclaimer attached to a patch,
then the copyright for the change is "implicitly" assigned to PGDG? (I'm
not a lawyer, but I believe that's not the case.)
I can tell you that it depends on the individuals relationship with
their employer. The employer may have agreement (most do) that will
state that whatever the employee does is owned by the employer.
Thus we may literally not have rights to the code. Do you really want to
go down the path of in 2 years, Fujitsu (No offense Fujitsu), but you
are the topic) decides that the code they provided is owned by them and
they didn't give us permission?
Joshua D. Drake
-Neil
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
On Tue, 2007-02-27 at 16:20 -0800, Joshua D. Drake wrote:
Thus we may literally not have rights to the code. Do you really want to
go down the path of in 2 years, Fujitsu (No offense Fujitsu), but you
are the topic) decides that the code they provided is owned by them and
they didn't give us permission?
For the case in question, sure, requiring some clarification from FJ
would be reasonable. But more broadly, my point is that I think you're
fooling yourself if you think that requiring a disclaimer or explicit
transfer of copyright for this *one* particular patch is likely to make
any material difference to the overall copyright status of the code
base.
-Neil
Neil Conway wrote:
On Tue, 2007-02-27 at 16:20 -0800, Joshua D. Drake wrote:
Thus we may literally not have rights to the code. Do you really want to
go down the path of in 2 years, Fujitsu (No offense Fujitsu), but you
are the topic) decides that the code they provided is owned by them and
they didn't give us permission?For the case in question, sure, requiring some clarification from FJ
would be reasonable. But more broadly, my point is that I think you're
fooling yourself if you think that requiring a disclaimer or explicit
transfer of copyright for this *one* particular patch is likely to make
any material difference to the overall copyright status of the code
base.
Yes, I do. If there is an explicit claim, like an email footer or a
copyright in the code, we do try to nail that down.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Hi,
A list of ctids is stored in the file.
The file is used to store the ctids during an updatable cursor transaction.
It is set up as a permanent file as it has a potential lifetime of
preserving data between crashes of the backend. Temporary files tend to be
used for data that is defined within a single command. In this case the file
needs to exist within a transaction and across backend processes.
The file gram.y has been corrected in my version.
The files ctidListStore.c and ctidListStore.h were pasted into the patch
file, as the diff -N command produced a file of several hundred thousand
lines.
Regards,
John Bartlett
-----Original Message-----
From: Heikki Linnakangas [mailto:hlinnaka@gmail.com] On Behalf Of Heikki
Linnakangas
Sent: Tuesday, 27 February 2007 10:03 PM
To: John Bartlett
Cc: pgsql-patches@postgresql.org; pgsql-hackers@postgresql.org
Subject: Re: [PATCHES]
John Bartlett wrote:
The community may wish to comment on the following issue:
1) At present the file that will contain the list of ctids is going
into
a new directory called pg_ctids, analogous to pg_twophase, and also stored
in the pg_data directory.
I don't understand this. What's stored in the file and why? If they're
only needed within the transaction, surely a temp file would be more
appropriate?
The new ctidListStore.c file in the patch is not in a valid diff-format.
I also noticed that you've moved the line beginning with "CREATE_ROLE"
in gram.y so that it's not in alphabetical order anymore.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
This is an email from Fujitsu Australia Software Technology Pty Ltd, ABN 27 003 693 481. It is confidential to the ordinary user of the email address to which it was addressed and may contain copyright and/or legally privileged information. No one else may read, print, store, copy or forward all or any of it or its attachments. If you receive this email in error, please return to sender. Thank you.
If you do not wish to receive commercial email messages from Fujitsu Australia Software Technology Pty Ltd, please email unsubscribe@fast.fujitsu.com.au
On Wed, 28 Feb 2007, John Bartlett wrote:
Hi,
A list of ctids is stored in the file.
I would have thought these would be stored in memory. If the set got
large, you'd use a temporary file the way other systems which overflow to
disk do?
The file is used to store the ctids during an updatable cursor transaction.
It is set up as a permanent file as it has a potential lifetime of
preserving data between crashes of the backend. Temporary files tend to be
used for data that is defined within a single command. In this case the file
needs to exist within a transaction and across backend processes.
It does not. Cursors are implicitly closed when a session is closed. A
backend crash or system restart closes all open sessions.
The file gram.y has been corrected in my version.
The files ctidListStore.c and ctidListStore.h were pasted into the patch
file, as the diff -N command produced a file of several hundred thousand
lines.
Edit the file with a text editor. If you know which files should be
excluded (like tags files), use diff --exclude=<pattern>.
Thanks,
Gavin
Bruce Momjian <bruce@momjian.us> writes:
Neil Conway wrote:
For the case in question, sure, requiring some clarification from FJ
would be reasonable. But more broadly, my point is that I think you're
fooling yourself if you think that requiring a disclaimer or explicit
transfer of copyright for this *one* particular patch is likely to make
any material difference to the overall copyright status of the code
base.
Yes, I do. If there is an explicit claim, like an email footer or a
copyright in the code, we do try to nail that down.
AFAICT, the footer in question tries to make it illegal for us even to
have the message in our mail archives. If I were running the PG lists,
I would install filters that automatically reject mails containing such
notices, with a message like "Your corporate lawyers do not deserve to
have access to the internet. Go away until you've acquired a clue."
I fully support Bruce's demand that patches be submitted with no such
idiocy attached.
regards, tom lane
Yes, I do. If there is an explicit claim, like an email footer or a
copyright in the code, we do try to nail that down.AFAICT, the footer in question tries to make it illegal for us even to
have the message in our mail archives. If I were running the PG lists,
I would install filters that automatically reject mails containing such
notices, with a message like "Your corporate lawyers do not deserve to
have access to the internet. Go away until you've acquired a clue."
Well that would pretty much eliminate the ability to receive mail from
any large company :) but I can certainly appreciate the sentiment.
I fully support Bruce's demand that patches be submitted with no such
idiocy attached.
Absolutely. In regards to your idea of a filter, there is no reason why
we couldn't install a filter that checks for signatures with specific
legal words and strips said signature automatically, responding to the
sender that we did so.
Joshua D. Drake
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
"Joshua D. Drake" <jd@commandprompt.com> writes:
... In regards to your idea of a filter, there is no reason why
we couldn't install a filter that checks for signatures with specific
legal words and strips said signature automatically, responding to the
sender that we did so.
The problem is that if $SENDER's corporate lawyers actually think that
it means something to put a restriction-of-rights notice on a message
sent to a public mailing list, then they might think that posting the
message with the notice stripped represents a violation of their barren
intellectual property :-(. What I'd like us to do is bounce it back.
A slightly cleaner version of the notice might be "If you wish to post
this message on our worldwide mailing lists, and thereby make unrepaid
use of our redistribution and archiving resources, then you may not
assert the right to restrict redistribution of your message."
Not that I think that anyone owning both a law degree and a computer
in 2007 should legitimately be able to plead innocence here. FAST
Australia's lawyers are making themselves look like idiots, and the
same for every other company tacking on such notices. I think the
real bottom line here is "we don't accept patches from idiots".
regards, tom lane
Not that I think that anyone owning both a law degree and a computer
in 2007 should legitimately be able to plead innocence here. FAST
Australia's lawyers are making themselves look like idiots, and the
same for every other company tacking on such notices. I think the
real bottom line here is "we don't accept patches from idiots".
Well the problem is, it isn't the guy that sent the patch that is the
idiot. That guys has zero control over the matter, the signature is
going to be tacked on at the MTA level.
I talked to my attorneys about this problem (not specific to postgresql
but in general) because my CPAs also have the same type of notice.
My attorney's response was that it is all about disclosure and covering
your butt. Not ours, but theirs. The idea being that they can say, "Look
we sent out the confidential disclosure, it isn't our fault the
recipients didn't listen."
Of course the joke here is, that the email went out on a public list and
is now mirrored all over the world and harvested by every spammer on the
planet ;)
However, it may be a good idea to have our (SPI) attorney at least give
us an official word on the matter. Thoughts?
Sincerely,
Joshua D. Drake
regards, tom lane
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
Tom Lane wrote:
"Joshua D. Drake" <jd@commandprompt.com> writes:
... In regards to your idea of a filter, there is no reason why
we couldn't install a filter that checks for signatures with specific
legal words and strips said signature automatically, responding to the
sender that we did so.The problem is that if $SENDER's corporate lawyers actually think that
it means something to put a restriction-of-rights notice on a message
sent to a public mailing list, then they might think that posting the
message with the notice stripped represents a violation of their barren
intellectual property :-(. What I'd like us to do is bounce it back.
A slightly cleaner version of the notice might be "If you wish to post
this message on our worldwide mailing lists, and thereby make unrepaid
use of our redistribution and archiving resources, then you may not
assert the right to restrict redistribution of your message."Not that I think that anyone owning both a law degree and a computer
in 2007 should legitimately be able to plead innocence here. FAST
Australia's lawyers are making themselves look like idiots, and the
same for every other company tacking on such notices. I think the
real bottom line here is "we don't accept patches from idiots".
I think "we don't accept patches from idiots" is a bit harsh.
There are quite a few skilled developers out there working for large
companies that are not doing most of their day-to-day business with OSS
software(and therefor know how to interact with the community).
Working in such a large environment requires one to use the tools and
infrastructure provided by the company - while I fully agree that email
sigs are one of the more stupid things it is often something the
individual person might not even know about (gets added at the gateway)
or can do much about it.
Stefan
"Joshua D. Drake" <jd@commandprompt.com> writes:
Well the problem is, it isn't the guy that sent the patch that is the
idiot. That guys has zero control over the matter, the signature is
going to be tacked on at the MTA level.
Sure, I know that and you know that. The problem we have to worry about
is that some PHB might later decide to sue us based on our having
ignored the pasted-on disclaimer. Now either the disclaimer means
something, in which case we had better cover our own butts by not
putting a restricted communication into our archives; or else it means
nothing, in which case the submitter can perfectly well resubmit it
without. But the present situation in which we accept and repost
messages containing these sorts of restrictions is the worst of all
possible worlds, because *we* can get sued if anyone is unhappy. Now
that is exactly the result desired by your standard corporate lawyer;
he's been trained to shift blame off his company onto any available
target. But I say it's not necessary, wise, nor moral for us to accept
such liability.
As to the original point, though: if the guy who sent the patch cannot
control the legalistic notices appended to his email, we must surely
not suppose that he has legal ownership of his work product. We need
a certification from his corporate lawyers that they won't sue us for
accepting the patch. If they don't feel the need for such formalities,
they should signal the world by not appending dam-fool notices to every
outgoing email.
regards, tom lane
Not that I think that anyone owning both a law degree and a computer
in 2007 should legitimately be able to plead innocence here. FAST
Australia's lawyers are making themselves look like idiots, and the
same for every other company tacking on such notices. I think the
real bottom line here is "we don't accept patches from idiots".I think "we don't accept patches from idiots" is a bit harsh.
I agree, after all, you've accepted some of my patches and... oh,
wait...
-- Korry
I have added this to the developer's FAQ to clarify the situtation of
posting a patch:
<li>PostgreSQL is licensed under a BSD license. By posting a patch
to the public PostgreSQL mailling lists, you are giving the PostgreSQL
Global Development Group the non-revokable right to distribute your
patch under the BSD license. If you use code that is available under
some other license that is BSD compatible (eg. public domain), please
note that in your email submission.</li>
---------------------------------------------------------------------------
Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
Neil Conway wrote:
For the case in question, sure, requiring some clarification from FJ
would be reasonable. But more broadly, my point is that I think you're
fooling yourself if you think that requiring a disclaimer or explicit
transfer of copyright for this *one* particular patch is likely to make
any material difference to the overall copyright status of the code
base.Yes, I do. If there is an explicit claim, like an email footer or a
copyright in the code, we do try to nail that down.AFAICT, the footer in question tries to make it illegal for us even to
have the message in our mail archives. If I were running the PG lists,
I would install filters that automatically reject mails containing such
notices, with a message like "Your corporate lawyers do not deserve to
have access to the internet. Go away until you've acquired a clue."I fully support Bruce's demand that patches be submitted with no such
idiocy attached.regards, tom lane
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote:
I have added this to the developer's FAQ to clarify the situtation of
posting a patch:<li>PostgreSQL is licensed under a BSD license. By posting a patch
to the public PostgreSQL mailling lists, you are giving the PostgreSQL
Global Development Group the non-revokable right to distribute your
patch under the BSD license. If you use code that is available under
some other license that is BSD compatible (eg. public domain), please
note that in your email submission.</li>
We should add this to the mailing list signup pages and the welcome
pages to the lists.
Joshua D. Drake
---------------------------------------------------------------------------
Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
Neil Conway wrote:
For the case in question, sure, requiring some clarification from FJ
would be reasonable. But more broadly, my point is that I think you're
fooling yourself if you think that requiring a disclaimer or explicit
transfer of copyright for this *one* particular patch is likely to make
any material difference to the overall copyright status of the code
base.Yes, I do. If there is an explicit claim, like an email footer or a
copyright in the code, we do try to nail that down.AFAICT, the footer in question tries to make it illegal for us even to
have the message in our mail archives. If I were running the PG lists,
I would install filters that automatically reject mails containing such
notices, with a message like "Your corporate lawyers do not deserve to
have access to the internet. Go away until you've acquired a clue."I fully support Bruce's demand that patches be submitted with no such
idiocy attached.regards, tom lane
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
Joshua D. Drake wrote:
Bruce Momjian wrote:
I have added this to the developer's FAQ to clarify the situtation of
posting a patch:<li>PostgreSQL is licensed under a BSD license. By posting a patch
to the public PostgreSQL mailling lists, you are giving the PostgreSQL
Global Development Group the non-revokable right to distribute your
patch under the BSD license. If you use code that is available under
some other license that is BSD compatible (eg. public domain), please
note that in your email submission.</li>We should add this to the mailing list signup pages and the welcome
pages to the lists.
Yep, good idea. Marc?
---------------------------------------------------------------------------
Joshua D. Drake
---------------------------------------------------------------------------
Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
Neil Conway wrote:
For the case in question, sure, requiring some clarification from FJ
would be reasonable. But more broadly, my point is that I think you're
fooling yourself if you think that requiring a disclaimer or explicit
transfer of copyright for this *one* particular patch is likely to make
any material difference to the overall copyright status of the code
base.Yes, I do. If there is an explicit claim, like an email footer or a
copyright in the code, we do try to nail that down.AFAICT, the footer in question tries to make it illegal for us even to
have the message in our mail archives. If I were running the PG lists,
I would install filters that automatically reject mails containing such
notices, with a message like "Your corporate lawyers do not deserve to
have access to the internet. Go away until you've acquired a clue."I fully support Bruce's demand that patches be submitted with no such
idiocy attached.regards, tom lane
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> writes:
Joshua D. Drake wrote:
We should add this to the mailing list signup pages and the welcome
pages to the lists.
Yep, good idea. Marc?
For -patches and -hackers, I agree. It seems a bit legalistic and
off-putting for the general lists, though.
regards, tom lane
FAST PostgreSQL wrote:
On Thu, 1 Mar 2007 04:28, Bruce Momjian wrote:
I have added this to the developer's FAQ to clarify the situtation of
posting a patch:<li>PostgreSQL is licensed under a BSD license. By posting a patch
to the public PostgreSQL mailling lists, you are giving the PostgreSQL
Global Development Group the non-revokable right to distribute your
patch under the BSD license. If you use code that is available under
some other license that is BSD compatible (eg. public domain), please
note that in your email submission.</li>We are happy to do this for every patch we submit. We can add an explicit
statement which will put our contribution under the BSD license. This
statement will override the email signature and will be approved by the
appropriate person.Rgds,
Arul Shaji
I know that I can speak for the community when I say, Thanks to you and
Fujitsu for taking our concerns into consideration.
Sincerely,
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
Import Notes
Reply to msg id not found: 13067.12191172708358.fast.fujitsu.com.au@MHS
On Wed, 28 Feb 2007 09:48, Bruce Momjian wrote:
[Added a subejct line]
FYI, I am not going to be comfortable accepting a final patch that
contains this email signature:This is an email from Fujitsu Australia Software Technology Pty Ltd, ABN
27 003 693 481. It is confidential to the ordinary user of the email
address to which it was addressed and may contain copyright and/or
---------------------
legally privileged information. No one else may read, print, store, copy
or forward all or any of it or its attachments. If you receive this
email in error, please return to s ender. Thank you.unless you provide additional details on your contribution of this code
under a BSD license.
We are happy to provide that. If and when it comes to the final patch being
accepted, we can send a copyright waiver mail which will put our source code
contribution under the BSD license.
Rgds,
Arul Shaji
---------------------------------------------------------------------------
John Bartlett wrote:
Hi,
This is the first posting to the community of the WIP patch for the
Updatable Cursor implementation.I want to confirm that the community is satisfied that the effort to date
is in a suitable direction and to get comments on the development to
date.The patch is in the following state:
The grammar definition is complete and 'yacc'ed to produce gram.y.c.
The functions transformUpdateStmt and transformDeleteStmt have been
updated to process the cursor name and obtain the related portal.The change to save the current tuple id (ctid) into the portal, related
to the Fetch command has been done.The ctids relating to the Update/Delete statements' TidScan are being
extracted to be saved in the executor.The parts in progress are to complete the saving of the ctids from the
TidScan into a list stored in a file, plus related searching the list for
an individual ctid obtained from the Update/Delete statements.Unstarted as yet:
1) Correctly process, in the database, the Delete / Update of
the tuple from the cursor.2) To enable the cursor name to be defined as a parameter in a
PREPARE statement and provided as part if an EXECUTE statement.The community may wish to comment on the following issue:
1) At present the file that will contain the list of ctids is going
into a new directory called pg_ctids, analogous to pg_twophase, and also
stored in the pg_data directory.Regards,
John BartlettThis is an email from Fujitsu Australia Software Technology Pty Ltd, ABN
27 003 693 481. It is confidential to the ordinary user of the email
address to which it was addressed and may contain copyright and/or
legally privileged information. No one else may read, print, store, copy
or forward all or any of it or its attachments. If you receive this email
in error, please return to sender. Thank you.If you do not wish to receive commercial email messages from Fujitsu
Australia Software Technology Pty Ltd, please email
unsubscribe@fast.fujitsu.com.au[ Attachment, skipping... ]
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
This is an email from Fujitsu Australia Software Technology Pty Ltd, ABN 27 003 693 481. It is confidential to the ordinary user of the email address to which it was addressed and may contain copyright and/or legally privileged information. No one else may read, print, store, copy or forward all or any of it or its attachments. If you receive this email in error, please return to sender. Thank you.
If you do not wish to receive commercial email messages from Fujitsu Australia Software Technology Pty Ltd, please email unsubscribe@fast.fujitsu.com.au
On Thu, 2007-03-01 at 15:17 +1100, FAST PostgreSQL wrote:
We are happy to provide that. If and when it comes to the final patch being
accepted, we can send a copyright waiver mail which will put our source code
contribution under the BSD license.
This approach is not practically workable and is a terrible shame.
What would happen if everybody said, "Well, since Fujitsu want to act
like that, we won't grant a BSD licence on our material until they grant
a BSD licence on theirs." Deadlock.
How do we know that you'll ever give that waiver? What would stop you
from making contributions right up to the last minute, receiving lots of
useful feedback, then at the last minute pulling the patch, once you
think its got no problems in it? If you do this, how will any of us fend
off *our* corporate lawyers who would like to do the same (probably)? Or
did you think the various companies on this list don't have any?
I provided my detailed implementation thoughts on the initial proposal.
Should I ignore posts from Fujitsu in the future because of this issue?
Open source requires trust, not legal brinkmanship. If you're even
thinking of submitting patches here, then it should already be clear
that the people on this list are better friends to you than people from
other companies who provide non-PostgreSQL-based services and products.
If you don't believe that, it seems better not to post at all.
I'll trust you, and hope that you'll grow to trust others back.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
On Thu, 1 Mar 2007 04:28, Bruce Momjian wrote:
I have added this to the developer's FAQ to clarify the situtation of
posting a patch:<li>PostgreSQL is licensed under a BSD license. By posting a patch
to the public PostgreSQL mailling lists, you are giving the PostgreSQL
Global Development Group the non-revokable right to distribute your
patch under the BSD license. If you use code that is available under
some other license that is BSD compatible (eg. public domain), please
note that in your email submission.</li>
We are happy to do this for every patch we submit. We can add an explicit
statement which will put our contribution under the BSD license. This
statement will override the email signature and will be approved by the
appropriate person.
Rgds,
Arul Shaji
---------------------------------------------------------------------------
Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
Neil Conway wrote:
For the case in question, sure, requiring some clarification from FJ
would be reasonable. But more broadly, my point is that I think you're
fooling yourself if you think that requiring a disclaimer or explicit
transfer of copyright for this *one* particular patch is likely to
make any material difference to the overall copyright status of the
code base.Yes, I do. If there is an explicit claim, like an email footer or a
copyright in the code, we do try to nail that down.AFAICT, the footer in question tries to make it illegal for us even to
have the message in our mail archives. If I were running the PG lists,
I would install filters that automatically reject mails containing such
notices, with a message like "Your corporate lawyers do not deserve to
have access to the internet. Go away until you've acquired a clue."I fully support Bruce's demand that patches be submitted with no such
idiocy attached.regards, tom lane
This is an email from Fujitsu Australia Software Technology Pty Ltd, ABN 27 003 693 481. It is confidential to the ordinary user of the email address to which it was addressed and may contain copyright and/or legally privileged information. No one else may read, print, store, copy or forward all or any of it or its attachments. If you receive this email in error, please return to sender. Thank you.
If you do not wish to receive commercial email messages from Fujitsu Australia Software Technology Pty Ltd, please email unsubscribe@fast.fujitsu.com.au
Hi Gavin,
Thanks for your comments.
I shall set up the ctids list to be stored in memory initially and dump to a
temp file if needed.
Regards,
John Bartlett
-----Original Message-----
From: pgsql-patches-owner@postgresql.org
[mailto:pgsql-patches-owner@postgresql.org] On Behalf Of Gavin Sherry
Sent: Wednesday, 28 February 2007 3:23 PM
To: John Bartlett
Cc: pgsql-hackers@postgresql.org; pgsql-patches@postgresql.org; 'Heikki
Linnakangas'
Subject: Re: [HACKERS] [PATCHES] - WIP Patch Updatable Cursor
On Wed, 28 Feb 2007, John Bartlett wrote:
Hi,
A list of ctids is stored in the file.
I would have thought these would be stored in memory. If the set got
large, you'd use a temporary file the way other systems which overflow to
disk do?
The file is used to store the ctids during an updatable cursor
transaction.
It is set up as a permanent file as it has a potential lifetime of
preserving data between crashes of the backend. Temporary files tend to be
used for data that is defined within a single command. In this case the
file
needs to exist within a transaction and across backend processes.
It does not. Cursors are implicitly closed when a session is closed. A
backend crash or system restart closes all open sessions.
The file gram.y has been corrected in my version.
The files ctidListStore.c and ctidListStore.h were pasted into the patch
file, as the diff -N command produced a file of several hundred thousand
lines.
Edit the file with a text editor. If you know which files should be
excluded (like tags files), use diff --exclude=<pattern>.
Thanks,
Gavin
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
This is an email from Fujitsu Australia Software Technology Pty Ltd, ABN 27 003 693 481. It is confidential to the ordinary user of the email address to which it was addressed and may contain copyright and/or legally privileged information. No one else may read, print, store, copy or forward all or any of it or its attachments. If you receive this email in error, please return to sender. Thank you.
If you do not wish to receive commercial email messages from Fujitsu Australia Software Technology Pty Ltd, please email unsubscribe@fast.fujitsu.com.au
On Fri, 2 Mar 2007 01:20, Simon Riggs wrote:
On Thu, 2007-03-01 at 15:17 +1100, FAST PostgreSQL wrote:
Hi Simon,
We are happy to provide that. If and when it comes to the final patch
being accepted, we can send a copyright waiver mail which will put our
source code contribution under the BSD license.This approach is not practically workable and is a terrible shame.
I already made a clarification on this subject yesterday.
http://archives.postgresql.org/pgsql-patches/2007-02/msg00579.php
It is for every patch we submit. Not just the final one.
I also sent a contribution statement yesterday regarding one of my patch
which is already pending.
http://archives.postgresql.org/pgsql-patches/2007-02/msg00581.php
What would happen if everybody said, "Well, since Fujitsu want to act
like that, we won't grant a BSD licence on our material until they grant
a BSD licence on theirs." Deadlock.How do we know that you'll ever give that waiver? What would stop you
from making contributions right up to the last minute, receiving lots of
useful feedback, then at the last minute pulling the patch, once you
think its got no problems in it? If you do this, how will any of us fend
off *our* corporate lawyers who would like to do the same (probably)? Or
did you think the various companies on this list don't have any?I provided my detailed implementation thoughts on the initial proposal.
Should I ignore posts from Fujitsu in the future because of this issue?Open source requires trust, not legal brinkmanship. If you're even
thinking of submitting patches here, then it should already be clear
that the people on this list are better friends to you than people from
other companies who provide non-PostgreSQL-based services and products.
If you don't believe that, it seems better not to post at all.I'll trust you, and hope that you'll grow to trust others back.
Of course it is. If we didn't trust the community, why would we even want to
contribute the source code in the first place.?
Rgds,
Arul Shaji
This is an email from Fujitsu Australia Software Technology Pty Ltd, ABN 27 003 693 481. It is confidential to the ordinary user of the email address to which it was addressed and may contain copyright and/or legally privileged information. No one else may read, print, store, copy or forward all or any of it or its attachments. If you receive this email in error, please return to sender. Thank you.
If you do not wish to receive commercial email messages from Fujitsu Australia Software Technology Pty Ltd, please email unsubscribe@fast.fujitsu.com.au
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Am playing with this now ... sorry for delay ...
- --On Wednesday, February 28, 2007 12:58:04 -0500 Tom Lane <tgl@sss.pgh.pa.us>
wrote:
Bruce Momjian <bruce@momjian.us> writes:
Joshua D. Drake wrote:
We should add this to the mailing list signup pages and the welcome
pages to the lists.Yep, good idea. Marc?
For -patches and -hackers, I agree. It seems a bit legalistic and
off-putting for the general lists, though.regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
- ----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . scrappy@hub.org MSN . scrappy@hub.org
Yahoo . yscrappy Skype: hub.org ICQ . 7615664
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (FreeBSD)
iD8DBQFF7NK+4QvfyHIvDvMRAgmcAJ9SFJPqi1awtlsSPHYMskH0qEXSdACfblCC
qODCB1vxRHBNwKj95pIOun4=
=Asm5
-----END PGP SIGNATURE-----
On Wed, 28 Feb 2007, Tom Lane wrote:
AFAICT, the footer in question tries to make it illegal for us even to
have the message in our mail archives. If I were running the PG lists,
I would install filters that automatically reject mails containing such
notices, with a message like "Your corporate lawyers do not deserve to
have access to the internet. Go away until you've acquired a clue."
I just noticed Bruce's email suggesting that this is going ahead:
http://archives.postgresql.org/pgsql-performance/2007-03/msg00098.php
I do not think this is a good idea. These disclaimer messages are
generally tacted on by the MTA of the company at which the person works,
as others have noted. There seem to be about 10 such emails to general per
month, not sure about other lists. FWIW, usually it is just one or two
offenders.
We do not suffer this problem in isolation. I think the Debian project has
tried to address this partly with this:
http://www.debian.org/MailingLists/disclaimer
Couldn't we place a disclaimer on the subscription page and welcome email
which says some of the interesting things in this disclaimer and says that
code contributions are implicitly licensed BSD. No idea about the legal
issues involved.
Another way of looking at this is that we cannot be 100% thorough. What
about disclaimers in German? What about false-positives?
Another concern I've had is that the assumption is that those wanting to
contribute (code) will just have to go register some throw away hotmail or
yahoo account. I think this will make tracing the origin of code more
difficult in the long term.
Just my thoughts.
Gavin
Gavin Sherry <swm@alcove.com.au> writes:
On Wed, 28 Feb 2007, Tom Lane wrote:
AFAICT, the footer in question tries to make it illegal for us even to
have the message in our mail archives. If I were running the PG lists,
I would install filters that automatically reject mails containing such
notices, with a message like "Your corporate lawyers do not deserve to
have access to the internet. Go away until you've acquired a clue."
I just noticed Bruce's email suggesting that this is going ahead:
http://archives.postgresql.org/pgsql-performance/2007-03/msg00098.php
I doubt that we'll go so far as to auto-bounce mail, but we definitely
are going to take a harder line about not accepting patches that are
submitted with such attachments.
Another concern I've had is that the assumption is that those wanting to
contribute (code) will just have to go register some throw away hotmail or
yahoo account. I think this will make tracing the origin of code more
difficult in the long term.
True, but having it definitely traceable to a company that had not given
permission for its use is not good either.
regards, tom lane