Skip site navigation (1) Skip section navigation (2)

== Wöchentlicher PostgreSQL Newsletter - 03. Augus 2008 ==

Subject: == Wöchentlicher PostgreSQL Newsletter - 03. Augus 2008 ==
Date: 2008-08-05 22:50:18
Message-ID: (view raw or flat)
Lists: pgsql-de-allgemein
Der Originalartikel befindet sich unter:

== Wöchentlicher PostgreSQL Newsletter - 03. Augus 2008 ==

Wenn du das liest, ist das Juli Commitfest bereits geschlossen. Viele
neue Features wurden hinzugefügt. Im September Commitfest kannst du
nach Common Table Expressions und Windowing Functions Ausschau halten.

== PostgreSQL Produkt Neuigkeiten ==

Npgsql2 RC1 erschienen.

pgbouncer 1.2.1 erschienen.

== PostgreSQL Lokal ==

pgDay San Francisco wird am 5. August stattfinden. Programm:
Anmeldung hier:

Die Prato Linux User Group wird PostgreSQL Vorträge im September
halten. Der Zeitplan in italienisch:

Sponsere den Europäischen PostgreSQL Tag!

Der Call for Papers für den Europäischen PostgreSQL Tag hat begonnen.

Anmeldung hier:


== PostgreSQL in den News ==

Planet PostgreSQL:

General Bits, Archive und gelegentliche News Artikel:

Dieser wöchentliche PostgreSQL Newsletter wurde erstellt von David

Sende Neuigkeiten und Ankündigungen bis Sonntag, 15 Uhr Pazifischer

== Angewandte Patches ==

Tom Lane committed:

- Update 8.1 and 8.0 plpython to work with Python 2.5.  This backports
  several fixes made during the 8.2 development cycle, but not
  backported at the time for lack of confidence in the new coding.  I
  didn't touch 7.4 because it has more problems than this: the
  configure probe for Python fails.

- Add a new, improved version of citext as a contrib module.  David E.

- Replace the hard-wired type knowledge in TypeCategory() and
  IsPreferredType() with system catalog lookups, as was foreseen to be
  necessary almost since their creation.  Instead put the information
  into two new pg_type columns, typcategory and typispreferred.  Add
  support for setting these when creating a user-defined base type.
  The category column is just a "char" (i.e. a poor man's enum),
  allowing a crude form of user extensibility of the category list:
  just use an otherwise-unused character.  This seems sufficient for
  foreseen uses, but we could upgrade to having an actual category
  catalog someday, if there proves to be a huge demand for custom type
  categories.  In this patch I have attempted to hew exactly to the
  behavior of the previous hardwired logic, except for introducing new
  type categories for arrays, composites, and enums.  In particular
  the default preferred state for user-defined types remains TRUE.
  That seems worth revisiting, but it should be done as a separate
  patch from introducing the infrastructure.  Likewise, any adjustment
  of the standard set of categories should be done separately.

- Adjust citext to make use of the new ability to declare its type
  category: by putting it into the standard string category, we cause
  casts from citext to text to be recognized as "preferred" casts.
  This eliminates the need for creation of alias functions and
  operators that only serve to prevent ambiguous-function errors; get
  rid of the ones that were in the original commit.

- Flip the default typispreferred setting from true to false.  This
  affects only type categories in which the previous coding made
  *every* type preferred; so there is no change in effective behavior,
  because the function resolution rules only do something different
  when faced with a choice between preferred and non-preferred types
  in the same category.  It just seems safer and less surprising to
  have CREATE TYPE default to non-preferred status ...

- Allow I/O conversion casts to be applied to or from any type that is
  a member of the STRING type category, thereby opening up the
  mechanism for user-defined types.  This is mainly for the benefit of
  citext, though; there aren't likely to be a lot of types that are
  all general-purpose character strings.  Per discussion with David

- Require superuser privilege to create base types (but not
  composites, enums, or domains).  This was already effectively
  required because you had to own the I/O functions, and the I/O
  functions pretty much have to be written in C since we don't let PL
  functions take or return cstring.  But given the possible security
  consequences of a malicious type definition, it seems prudent to
  enforce superuser requirement directly.  Per recent discussion.

- Fix parser so that we don't modify the user-written ORDER BY list in
  order to represent DISTINCT or DISTINCT ON.  This gets rid of a
  longstanding annoyance that a view or rule using SELECT DISTINCT
  will be dumped out with an overspecified ORDER BY list, and is one
  small step along the way to decoupling DISTINCT and ORDER BY enough
  so that hash-based implementation of DISTINCT will be possible.  In
  passing, improve transformDistinctClause so that it doesn't reject
  duplicate DISTINCT ON items, as was reported by Steve Midgley a
  couple weeks ago.

- Rearrange the querytree representation of ORDER BY/GROUP BY/DISTINCT
  items as per my recent proposal: 1. Fold SortClause and GroupClause
  into a single node type SortGroupClause.  We were already relying on
  them to be struct-equivalent, so using two node tags wasn't
  accomplishing much except to get in the way of comparing items with
  equal().  2. Add an "eqop" field to SortGroupClause to carry the
  associated equality operator.  This is cheap for the parser to get
  at the same time it's looking up the sort operator, and storing it
  eliminates the need for repeated not-so-cheap lookups during
  planning.  In future this will also let us represent GROUP/DISTINCT
  operations on datatypes that have hash opclasses but no btree
  opclasses (ie, they have equality but no natural sort order).  The
  previous representation simply didn't work for that, since its only
  indicator of comparison semantics was a sort operator.  3. Add a
  hasDistinctOn boolean to struct Query to explicitly record whether
  the distinctClause came from DISTINCT or DISTINCT ON.  This allows
  removing some complicated and not 100% bulletproof code that
  attempted to figure that out from the distinctClause alone.  This
  patch doesn't in itself create any new capability, but it's
  necessary infrastructure for future attempts to use hash-based

- In pgsql/src/test/regress/pg_regress.c, fix copy-and-pasteo that's
  causing pg_regress to lie about which file it can't read when the
  --temp-config argument is bad.  Noted while wondering why buildfarm
  member dungbeetle is failing ... this isn't why, but it is why the
  error report isn't very helpful ...

- In pgsql/src/backend/catalog/pg_type.c, tighten up the sanity checks
  in TypeCreate(): pass-by-value types must have a size that is one of
  the supported values, not just anything <= sizeof(Datum).
  Cross-check the alignment specification against size as well.

- Make GROUP BY work properly for datatypes that only support hashing
  and not sorting.  The infrastructure for this was all in place
  already; it's only necessary to fix the planner to not assume that
  sorting is always an available option.

Magnus Hagander committed:

- In pgsql/doc/src/sgml/install-win32.sgml, document which versions of
  ActivePerl and ActiveTcl are required for building on MSVC, and that
  the free distribution is enough (no need for the enterprise
  version).  Per gripe from Martin Zaun.

- In pgsql/doc/src/sgml/install-win32.sgml, clean up reference to so it makes sense not only in SGML source but in the
  actual web/pdf viewer...

- Move ident authentication code into auth.c along with the other
  authenciation routines, leaving hba.c to deal only with processing
  the HBA specific files.

- In pgsql/src/backend/libpq/auth.c, rearrange the code in auth.c so
  that all functions for a single authentication method is grouped
  together in a reasonably similar way, keeping the "global shared
  functions" together in their own section as well. Makes it a lot
  easier to find your way around the code.

Bruce Momjian committed:

- Add URL for TODO: "Consider decreasing the I/O caused by updating
  tuple hint bits."

Alvaro Herrera committed:

- Add a few more DTrace probes to the backend.  Robert Lor.

- Cope with Tcl versions that do not create a tclsh symlink to the
  version- numbered program.  Per persistent buildfarm failures.  Tom

== Abgelehnte Patches (bis jetzt) ==

No one was disappointed this week :-)

== Eingesandte Patches ==

Tatsuo Ishii sent in another revision of Yoshiuki Asaba's CTE patch.

Hitoshi Harada sent in another revision of his windowing functions

Jan Urbanski sent in two more revisions of his patch to add
selectivity functions for text search types.


Abhijit Menon-Sen sent in two more revisions of his \ef (edit
function) patch for psql along with a patch to add
pg_get_functiondef() as an SQL-callable function.

Robert Lor sent in two more revisions of his DTrace probes patch.

ITAGAKI Takahiro sent in a patch to add STORAGE and reloptions to

Alvaro Herrera sent in two updates to Robert Lor's DTrace probes

ITAGAKI Takahiro sent in a patch to use NDirectFileRead and
NDirectFileWrite statistics counters for counting reads and writes in

Heikki Linnakangas sent in new revisions of his Relation Forks and FSM
rewrite patches, the latter depending on the former.

		Andreas 'ads' Scherbaum
Deutsche PostgreSQL User Group:

pgsql-de-allgemein by date

Next:From: Albe LaurenzDate: 2008-08-06 07:22:53
Subject: RE: [pgsql-de-allgemein] In Funktion prüfen ob Zei?==?iso-8859-1?Q?le existiert
Previous:From: Bernd HelmleDate: 2008-08-05 22:33:39
Subject: Re: In Funktion prüfen ob Zeile existiert

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group