Re: [PATCHES] Standard compliant DEFAULT clause
Tom Lane írta: Zoltan Boszormenyi [EMAIL PROTECTED] writes: Or not, it's just a bitter and late (because of my bitterness) response to the rejection of my IDENTITY/GENERATED patches. Where's the much praised standard behaviour on standard syntax? So much for hypocrisy. Hm? There's a difference between extensions and failing to comply with what the spec says is the behavior of the syntax it provides. OK, that's where POVs and interpretations may differ. :-) The standard says one thing (allow these and only these kinds of expressions) which is a description of a behaviour, or can be interpreted as one. Now, if you allow others as well, is it an extension or failing to comply? :-) I have another question. How many features PostgreSQL have that copies other DMBS' behaviour (say, because of easy porting) and as such, differs slightly from the standard? Someone quoted DB2 during the early life of my patch, and it seems to me after reading DB2's online docs that GENERATED BY DEFAULT AS IDENTITY there behaves the was SERIAL behaves in PostgreSQL and the standard draft's text can be interpreted that way as well. I feel bad that you put so much work into what now seems to be a dead end (at least until we can get some clarification about what the committee really intends). But look at the bright side: you learned quite a bit about the innards of Postgres. Hopefully your next project will be more successful. regards, tom lane Thanks for the encouragement. I just needed to blow the the steam off somehow. Maybe the word hypocrisy was too harsh, sorry for that. I will shut up now. -- -- Zoltán Böszörményi Cybertec Geschwinde Schönig GmbH http://www.postgresql.at/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Maintaining cluster order on insert
Jaime Casanova wrote:
On 5/18/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Jaime Casanova wrote:
the patch doesn't apply in cvs... you'll need to update it...
Oh, here you are.
The implementation has changed a bit since August. I thought I had
submitted an updated version in the winter but couldn't find it. Anyway,
I updated and dusted off the source tree, tidied up the comments a
little bit, and fixed some inconsistencies in pg_proc entries that made
opr_sanity to fail.
this one doesn't apply either... there are problems with nbtinsert.c and
pg_am.h
Ah, sorry about that. For some reason my source tree was checked out
from the 8.2 branch, instead of CVS HEAD.
Here you are. Thanks for looking at this!
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Index: doc/src/sgml/catalogs.sgml
===
RCS file: /home/hlinnaka/pgcvsrepository/pgsql/doc/src/sgml/catalogs.sgml,v
retrieving revision 2.152
diff -c -r2.152 catalogs.sgml
*** doc/src/sgml/catalogs.sgml 15 May 2007 19:13:54 - 2.152
--- doc/src/sgml/catalogs.sgml 19 May 2007 16:23:49 -
***
*** 517,522
--- 517,536
entryFunction to parse and validate structfieldreloptions/ for an index/entry
/row
+ row
+ entrystructfieldamprepareinsert/structfield/entry
+ entrytyperegproc/type/entry
+ entryliterallink linkend=catalog-pg-procstructnamepg_proc/structname/link.oid/literal/entry
+ entryPerforms the 1st phase of a two phase index insert, returning a suggestion of where in the heap to put a new tuple/entry
+ /row
+
+ row
+ entrystructfieldamfinishinsert/structfield/entry
+ entrytyperegproc/type/entry
+ entryliterallink linkend=catalog-pg-procstructnamepg_proc/structname/link.oid/literal/entry
+ entryFinishes an index insert started with amprepareinsert/entry
+ /row
+
/tbody
/tgroup
/table
Index: src/backend/access/heap/heapam.c
===
RCS file: /home/hlinnaka/pgcvsrepository/pgsql/src/backend/access/heap/heapam.c,v
retrieving revision 1.232
diff -c -r1.232 heapam.c
*** src/backend/access/heap/heapam.c 8 Apr 2007 01:26:27 - 1.232
--- src/backend/access/heap/heapam.c 19 May 2007 16:45:14 -
***
*** 1368,1373
--- 1368,1377
* Note that use_wal and use_fsm will be applied when inserting into the
* heap's TOAST table, too, if the tuple requires any out-of-line data.
*
+ * If suggested_blk is a valid block number, the tuple will be inserted to
+ * that block if there's enough room. If it's full, a block will be chosen
+ * as if suggested_blk was not set.
+ *
* The return value is the OID assigned to the tuple (either here or by the
* caller), or InvalidOid if no OID. The header fields of *tup are updated
* to match the stored tuple; in particular tup-t_self receives the actual
***
*** 1376,1382
*/
Oid
heap_insert(Relation relation, HeapTuple tup, CommandId cid,
! bool use_wal, bool use_fsm)
{
TransactionId xid = GetCurrentTransactionId();
HeapTuple heaptup;
--- 1380,1386
*/
Oid
heap_insert(Relation relation, HeapTuple tup, CommandId cid,
! bool use_wal, bool use_fsm, BlockNumber suggested_blk)
{
TransactionId xid = GetCurrentTransactionId();
HeapTuple heaptup;
***
*** 1432,1440
else
heaptup = tup;
! /* Find buffer to insert this tuple into */
! buffer = RelationGetBufferForTuple(relation, heaptup-t_len,
! InvalidBuffer, use_fsm);
/* NO EREPORT(ERROR) from here till changes are logged */
START_CRIT_SECTION();
--- 1436,1478
else
heaptup = tup;
! /* Find buffer to insert this tuple into. Try the suggested block first
! * if caller gave one.
! */
! if (suggested_blk != InvalidBlockNumber)
! {
! Buffer suggested_buf;
! Page pageHeader;
! Size pageFreeSpace;
!
! suggested_buf = ReadBuffer(relation, suggested_blk);
! pageHeader = (Page) BufferGetPage(suggested_buf);
!
! LockBuffer(suggested_buf, BUFFER_LOCK_EXCLUSIVE);
!
! /* Don't subtract fillfactor from the free space. That space is
! * reserved exactly for situations like this; keeping updated and
! * inserted tuples close to other tuples with similar values.
! */
! pageFreeSpace = PageGetFreeSpace(pageHeader);
!
! if (heaptup-t_len = pageFreeSpace)
! buffer = suggested_buf;
! else
! {
! /* Page was full. Release lock and pin and get another block
! * as if suggested_blk was not given.
! */
! LockBuffer(suggested_buf, BUFFER_LOCK_UNLOCK);
! ReleaseBuffer(suggested_buf);
!
! buffer = RelationGetBufferForTuple(relation, heaptup-t_len,
! InvalidBuffer, use_fsm);
! }
! }
! else
! buffer = RelationGetBufferForTuple(relation, heaptup-t_len,
! InvalidBuffer, use_fsm);
Re: [PATCHES] Maintaining cluster order on insert
Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --- Heikki Linnakangas wrote: Jaime Casanova wrote: On 5/18/07, Heikki Linnakangas [EMAIL PROTECTED] wrote: Jaime Casanova wrote: the patch doesn't apply in cvs... you'll need to update it... Oh, here you are. The implementation has changed a bit since August. I thought I had submitted an updated version in the winter but couldn't find it. Anyway, I updated and dusted off the source tree, tidied up the comments a little bit, and fixed some inconsistencies in pg_proc entries that made opr_sanity to fail. this one doesn't apply either... there are problems with nbtinsert.c and pg_am.h Ah, sorry about that. For some reason my source tree was checked out from the 8.2 branch, instead of CVS HEAD. Here you are. Thanks for looking at this! -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 1: 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 -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] Updateable cursors patch
On 5/17/07, Jaime Casanova [EMAIL PROTECTED] wrote: On 5/17/07, FAST PostgreSQL [EMAIL PROTECTED] wrote: No. It works with scrollable cursors. It will work for cursors/selects which does not put the results in some store, such as WITH hold/group by/order by etc But most of these restrictions apply for normal 'Select for update' anyway. (With the order by clause, the implementation is as per the sql standards.) your patch doesn't work with updatable views because they don't have ctid columns ERROR: column ctid does not exist STATEMENT: update vfoo set des_cta = des_cta || ' - prueba' where current of foo; ERROR: current transaction is aborted, commands ignored until end of transaction block is this sane behavior? to accept create cursors for update on views and then failing to update where current of and rollback the entire transaction? comments? maybe just send a better error message -- regards, Jaime Casanova Programming today is a race between software engineers striving to build bigger and better idiot-proof programs and the universe trying to produce bigger and better idiots. So far, the universe is winning. Richard Cook ---(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
