with index qual clauses in the Path representation. This saves a little
work during createplan and (probably more importantly) allows reuse of
cached selectivity estimates during indexscan planning. Also fix latent
bug: wrong plan would have been generated for a 'special operator' used
in a nestloop-inner-indexscan join qual, because the special operator
would not have gotten into the list of quals to recheck. This bug is
only latent because at present the special-operator code could never
trigger on a join qual, but sooner or later someone will want to do it.
run the data through cpp, and we know of at least one platform where
unusual cpp behavior breaks the process. So remove the cpp step,
and make consequent simplifications.
conditions is overkill; set_union() does the job about as well, and
much more efficiently. Furthermore this avoids assuming that
canonicalize_qual() will check for duplicate clauses at all, which
it may not always do.
about whether it is applied before or after eval_const_expressions().
I believe there were some corner cases where the system would fail to
recognize that a partial index is applicable because of the previous
inconsistency. Store normal rather than 'implicit AND' representations
of constraints and index predicates in the catalogs.
initdb forced due to representation change of constraints/predicates.
> > needed, and other people in the past asked about it too.
>
> It is in Oracle, but you aren't exactly on the spot. It should be
>
> IYYY - 4 digits ('2003')
> IYY - 3 digits ('003')
> IY - 2 digits ('03')
> I - 1 digit ('3')
Here is an updated patch that does that.
Kurt Roeckx
> Attached is a patch that addressed all the discussed issues
> that did not break backward compatability, including the
> ability to output ISO-8601 compliant intervals by setting
> datestyle to iso8601basic.
a) ones that are 100% backward (such as the comment about
outputting this format)
and
b) ones that aren't (such as deprecating the current
postgresql shorthand of
'1Y1M'::interval = 1 year 1 minute
in favor of the ISO-8601
'P1Y1M'::interval = 1 year 1 month.
Attached is a patch that addressed all the discussed issues that
did not break backward compatability, including the ability to
output ISO-8601 compliant intervals by setting datestyle to
iso8601basic.
Interval values can now be written as ISO 8601 time intervals, using
the "Format with time-unit designators". This format always starts with
the character 'P', followed by a string of values followed
by single character time-unit designators. A 'T' separates the date and
time parts of the interval.
Ron Mayer
to certain compile-time options (FUNC_MAX_ARGS, INDEX_MAX_KEYS,
NAMEDATALEN, BLCKSZ, HAVE_INT64_TIMESTAMP). Also added "category",
"short_desc", and "extra_desc" to the pg_settings view. Per recent
discussion here:
http://archives.postgresql.org/pgsql-patches/2003-11/msg00363.php
and hash bucket-size estimation. Issue has been there awhile but is more
critical in 7.4 because it affects varchar columns. Per report from
Greg Stark.
proposal for eventually deprecating OIDs on user tables that I posted
earlier to pgsql-hackers. pg_dump now always specifies WITH OIDS or
WITHOUT OIDS when dumping a table. The documentation has been updated.
Neil Conway
to note:
1) arttype is numeric. I thought this was the best way of allowing
arbitarily large factorials, even though factorial(2^63) is a large
number. Happy to change to integers if this is overkill.
2) since we're accepting numeric arguments, the patch tests for floats.
If a numeric is passed with non-zero decimal portion, an error is raised
since (from memory) they are undefined.
Gavin Sherry
This first part of the background writer does no syncing at all.
It's only purpose is to keep the LRU heads clean so that regular
backends seldom to never have to call write().
Jan
which had been unintentionally broken by recent changes to tighten up the
DateStyle rules for all-numeric date input. Add documentation and
regression tests for this, too.
pghackers proposal of 8-Nov. All the existing cross-type comparison
operators (int2/int4/int8 and float4/float8) have appropriate support.
The original proposal of storing the right-hand-side datatype as part of
the primary key for pg_amop and pg_amproc got modified a bit in the event;
it is easier to store zero as the 'default' case and only store a nonzero
when the operator is actually cross-type. Along the way, remove the
long-since-defunct bigbox_ops operator class.
Remove the 'strategy map' code, which was a large amount of mechanism
that no longer had any use except reverse-mapping from procedure OID to
strategy number. Passing the strategy number to the index AM in the
first place is simpler and faster.
This is a preliminary step in planned support for cross-datatype index
operations. I'm committing it now since the ScanKeyEntryInitialize()
API change touches quite a lot of files, and I want to commit those
changes before the tree drifts under me.
rule split the query into one INSERT and one UPDATE where the UPDATE
then hit's the just created row without modifying the key fields again.
In this special case, the new key slipped in totally unchecked.
Jan
ACL array, and force languages to be treated as owned by the bootstrap
user ID. (pg_language should have a lanowner column, but until it does
this will have to do as a workaround.)
a single LEFT JOIN query instead of firing the check trigger for each
row individually. Stephan Szabo, with some kibitzing from Tom Lane and
Jan Wieck.
with required outer parentheses. Breakage seems to be leftover from
domain-constraint patches. This could be smarter about suppressing
extra parens, but at this stage of the release cycle I want certainty
not cuteness.
of function bodies is done at CREATE FUNCTION time. This is normally
true but can be set false to avoid problems with forward references,
wrong schema search path, etc. This is just the backend patch, still
need to adjust pg_dump to make use of it.
in the schema search path. Otherwise pg_dump doesn't correctly dump
scenarios where a custom opclass is created in 'public' and then used
by indexes in other schemas.
discussion on pgsql-hackers: in READ COMMITTED mode we just have to force
a QuerySnapshot update in the trigger, but in SERIALIZABLE mode we have
to run the scan under a current snapshot and then complain if any rows
would be updated/deleted that are not visible in the transaction snapshot.
Before patch:
test=# select pg_get_constraintdef(oid) from pg_constraint;
pg_get_constraintdef
-------------------------------------------------------------------------------------------------
CHECK (VALUE >= 0)
CHECK ((((a)::text = 'asdf'::text) OR ((a)::text = 'fdsa'::text)) OR
((a)::text = 'dfd'::text))
PRIMARY KEY (b)
FOREIGN KEY (a) REFERENCES test2(b)
UNIQUE (b)
(5 rows)
test=# select pg_get_constraintdef(oid, true) from pg_constraint;
pg_get_constraintdef
-----------------------------------------------------------------------------------
CHECK VALUE >= 0
CHECK a::text = 'asdf'::text OR a::text = 'fdsa'::text OR a::text =
'dfd'::text
PRIMARY KEY (b)
FOREIGN KEY (a) REFERENCES test2(b)
UNIQUE (b)
(5 rows)
After patch:
test=# select pg_get_constraintdef(oid) from pg_constraint;
pg_get_constraintdef
-------------------------------------------------------------------------------------------------
CHECK (VALUE >= 0)
CHECK ((((a)::text = 'asdf'::text) OR ((a)::text = 'fdsa'::text)) OR
((a)::text = 'dfd'::text))
PRIMARY KEY (b)
FOREIGN KEY (a) REFERENCES test2(b)
UNIQUE (b)
(5 rows)
test=# select pg_get_constraintdef(oid, true) from pg_constraint;
pg_get_constraintdef
-----------------------------------------------------------------------------------
CHECK (VALUE >= 0)
` CHECK (a::text = 'asdf'::text OR a::text = 'fdsa'::text OR a::text =
'dfd'::text)
PRIMARY KEY (b)
FOREIGN KEY (a) REFERENCES test2(b)
UNIQUE (b)
(5 rows)
It's important that those brackets are there to (a) match all other
constraints and (b) so that people can just copy and paste them and it
will work as SQL.
Christopher Kings-Lynne
