report on old-style functions invoked by RI triggers. We had a number of
other places that were being sloppy about which memory context FmgrInfo
subsidiary data will be allocated in. Turns out none of them actually
cause a problem in 7.1, but this is for arcane reasons such as the fact
that old-style triggers aren't supported anyway. To avoid getting burnt
later, I've restructured the trigger support so that we don't keep trigger
FmgrInfo structs in relcache memory. Some other related cleanups too:
it's not really necessary to call fmgr_info at all while setting up
the index support info in relcache entries, because those ScanKeyEntry
structs are never used to invoke the functions. This should speed up
relcache initialization a tiny bit.
7.7. Keys
you have
However, my application requires that each collection will also have a
unique name. Why? So that a human being who wants to modify a collection
will be able to identify it. It's much harder to know, if you have two
collections named "Life Science", the the one tagged 24433 is the one
you
need, and the one tagged 29882 is not
I think 'the the' shouldn't be repeated twice. Although taken from an
email it would be cool to fix.
Cheers,
Maxim Maletsky
which says that PERFORM will execute any SELECT query and discard the
result. The former implementation would in fact raise an error if the
result contained more than one row or more than one column.
Also, change plpgsql's error-logging mechanism to emit the additional
messages about error location at NOTICE rather than DEBUG level. This
allows them to be seen by the client without having to dig into the
postmaster log file (which may be nonexistent or inaccessible by the
client).
Indicies: palm_buy_date_idx
palm_user_date_idx
Primary Key: palm_buyers_pkey
Unique Key: palm_buyers_username
Constraint: "$1" ((sex = 'M'::bpchar) OR (sex = 'F'::bpchar))
Note that check constraint name now shown as well. (Makes it a lot easier
to test inheritance support in ADD/DROP constraint :) )
Attached is a docs change for psql.
Christopher Kings
Python) to support shared extension modules, I have learned that Guido
prefers the style of the attached patch to solve the above problem.
I feel that this solution is particularly appropriate in this case
because the following:
PglargeType
PgType
PgQueryType
are already being handled in the way that I am proposing for PgSourceType.
Jason Tishler
it does not support 64bit integers. AFAIK that's the default data type for
OIDs, so I am not surprised that this does not work. Use gcc instead.
BTW., 7.1 does not compile as is with gcc either, I believed the
required patches made it into the 7.1.1 release but obviously I missed
the deadline.
Since the ports mailing list does not seem to be archived I have attached
a copy of the patch (for 7.1 and 7.1.1).
I've just performed a build of a Watcom compiled version and found a couple
of bugs in the watcom specific part of that patch. Please use the attached
version instead.
Tegge, Bernd
to do that, but inconsistently.) Make bit type reject too short input,
too, per SQL. Since it no longer zero pads, 'zpbit*' has been renamed to
'bit*' in the source, hence initdb.
