Skip to content

G
Gpdb

Greenplum / Gpdb

通知 7
Star 1
Fork 0
G
Gpdb

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 02 7月, 2006 2 次提交
    • B
      Done: · ff3003e5
      由 Bruce Momjian 提交于 
      < 	o Add ALTER TABLE tab ADD/DROP INHERITS parent
<
< 	  This allows tables to be added/removed from an inheritance
< 	  hierarchy.  This is particularly useful for table partitioning.
< 	  http://archives.postgresql.org/pgsql-hackers/2006-05/msg00988.php
<
> 	o -Add ALTER TABLE tab INHERIT / NO INHERIT  parent
      ff3003e5
    • B
      ALTER TABLE ... ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) · 8c092781
      由 Bruce Momjian 提交于 
      Open items:

There were a few tangentially related issues that have come up that I think
are TODOs. I'm likely to tackle one or two of these next so I'm interested in
hearing feedback on them as well.

. Constraints currently do not know anything about inheritance. Tom suggested
  adding a coninhcount and conislocal like attributes have to track their
  inheritance status.

. Foreign key constraints currently do not get copied to new children (and
  therefore my code doesn't verify them). I don't think it would be hard to
  add them and treat them like CHECK constraints.

. No constraints at all are copied to tables defined with LIKE. That makes it
  hard to use LIKE to define new partitions. The standard defines LIKE and
  specifically says it does not copy constraints. But the standard already has
  an option called INCLUDING DEFAULTS; we could always define a non-standard
  extension LIKE table INCLUDING CONSTRAINTS that gives the user the option to
  request a copy including constraints.

. Personally, I think the whole attislocal thing is bunk. The decision about
  whether to drop a column from children tables or not is something that
  should be up to the user and trying to DWIM based on whether there was ever
  a local definition or the column was acquired purely through inheritance is
  hardly ever going to match up with user expectations.

. And of course there's the whole unique and primary key constraint issue. I
  think to get any traction at all on this you have a prerequisite of a real
  partitioned table implementation where the system knows what the partition
  key is so it can recognize when it's a leading part of an index key.

Greg Stark
      8c092781
  3. 30 6月, 2006 2 次提交
    • B
      Update item for GUID: · 569e32a0
      由 Bruce Momjian 提交于 
      < * Add 128-bit Universally Unique Identifier (UUID)
> * Add Globally/Universally Unique Identifier (GUID/UUID)
      569e32a0
    • T
      Remove the separate 'stats buffer' process, letting backend stats messages · 51e400c9
      由 Tom Lane 提交于 
      be delivered directly to the collector process.  The extra process context
swaps required to transfer data through the buffer process seem to outweigh
any value the buffering might have.  Per recent discussion and tests.
I modified Bruce's draft patch to use poll() rather than select() where
available (this makes a noticeable difference on my system), and fixed
up the EXEC_BACKEND case.
      51e400c9
  5. 29 6月, 2006 4 次提交
  7. 28 6月, 2006 7 次提交
  9. 27 6月, 2006 5 次提交
    • B
      Add INCLUDING CONSTRAINTS to CREATE TABLE LIKE. · dc2c25fc
      由 Bruce Momjian 提交于 
      Greg Stark
      dc2c25fc
    • B
      Done: · 62f26936
      由 Bruce Momjian 提交于 
      < * %Disallow changing DEFAULT expression of a SERIAL column?
<
<   This should be done only if the existing SERIAL problems cannot be
<   fixed.
<
> * -Disallow changing DEFAULT expression of a SERIAL column
      62f26936
    • B
      Done: · 560feb47
      由 Bruce Momjian 提交于 
      > 	o -Add PQescapeIdentifier()
      560feb47
    • B
      Add PQescapeIdentifier() to libpq · 3b1790f9
      由 Bruce Momjian 提交于 
      Christopher Kings-Lynne
      3b1790f9
    • T
      Change the row constructor syntax (ROW(...)) so that list elements foo.* · ca0d2197
      由 Tom Lane 提交于 
      will be expanded to a list of their member fields, rather than creating
a nested rowtype field as formerly.  (The old behavior is still available
by omitting '.*'.)  This syntax is not allowed by the SQL spec AFAICS,
so changing its behavior doesn't violate the spec.  The new behavior is
substantially more useful since it allows, for example, triggers to check
for data changes with 'if row(new.*) is distinct from row(old.*)'.  Per
my recent proposal.
      ca0d2197
  11. 26 6月, 2006 3 次提交
  13. 25 6月, 2006 2 次提交
    • B
      Update entry: · ac7a126d
      由 Bruce Momjian 提交于 
      < * Allow heap reuse of UPDATEd rows if old and new versions are on the
<   same heap page?
> * Allow heap reuse of UPDATEd rows if no indexed columns are changed,
>   and old and new versions are on the same heap page?
<   This is possible for same-page updates because a single index row
<   can point to both old and new values.
>   While vacuum handles DELETEs fine, updating of non-indexed columns, like
>   counters, are difficult for VACUUM to handle efficiently.  This method
>   is possible for same-page updates because a single index row can be
>   used to point to both old and new values.
      ac7a126d
    • B
      Add UPDATE entry for row reuse. · fc6a2293
      由 Bruce Momjian 提交于 
      >
> * Allow heap reuse of UPDATEd rows if old and new versions are on the
>   same heap page?
>
>   This is possible for same-page updates because a single index row
>   can point to both old and new values.
>   http://archives.postgresql.org/pgsql-hackers/2006-06/msg01305.php
      fc6a2293
  15. 20 6月, 2006 1 次提交
  17. 19 6月, 2006 2 次提交
  19. 18 6月, 2006 1 次提交
  21. 17 6月, 2006 11 次提交