Same code exactly as for function resolution.
An obvious example is for
select '1' = '01';
which used to throw an error and which now resolves to two text strings.
Previously, all fields were unsigned, with only a trailing "ago" to
indicate negative intervals. Now, ISO format does not use "ago", and
and the traditional PostgreSQL format has the first numeric field unsigned
with "ago" supporting that field. So "1 month - 2 days ago" is two days
less than a month in the past.
Fix interval arithmetic across daylight savings time boundaries.
Previously, most math across boundaries introduced a one hour offset.
Allow some date/time functions to return NULL if called with NULL args.
Implement functions for AT TIME ZONE support.
Support "SAT" as an Australian time zone if USE_AUSTRALIAN_RULES
is defined.
any available string type. Previously, all candidate choices must have
fallen within the same "type category" for PostgreSQL to be willing to
choose any of them.
Need to apply the same fixup to operator type resolution.
Bruce Hartzler <bruceh@mail.utexas.edu>. It contains shared library
support, regression test map, and the usual template files. The dynamic
loader is missing, the spin lock code apparently doesn't assemble due to
syntax problems, and semaphores are to be hoped for from Apple.
position() and substring() functions, so that it works transparently for
bit types as well. Alias the text functions appropriately.
Add position() for bit types.
Add new constant node T_BitString that represents literals of the form
B'1001 and pass those to zpbit type.
equivalent.
In linux.h there were some #undef HAVE_INT_TIMEZONE, which are useless
because HAVE_TM_ZONE overrides it anyway, and messing with configure
results isn't cool.
subqueries. It passes the normal 'runcheck' tests, and I've tried
a few simple things like
select 1 as foo union (((((select 2))))) order by foo;
There are a few things that it doesn't do that have been talked
about here at least a little:
1) It doesn't allow things like "IN(((select 1)))" -- the select
here has to be at the top level. This is not new.
2) It does NOT preserve the odd syntax I found when I started looking
at this, where a SELECT statement could begin with parentheses. Thus,
(SELECT a from foo) order by a;
fails.
I have preserved the ability, used in the regression tests, to
have a single select statement in what appears to be a RuleActionMulti
(but wasn't -- the parens were part of select_clause syntax).
In my version, this is a special form.
This may cause some discussion: I have differentiated the two kinds
of RuleActionMulti. Perhaps nobody knew there were two kinds, because
I don't think the second form appears in the regression tests. This
one uses square brackets instead of parentheses, but originally was
otherwise the same as the one in parentheses. In this version of
gram.y, the square bracket form treats SELECT statements the same
as the other allowed statements. As discussed before on this list,
psql cannot make sense out of the results of such a thing, but an
application might. And I have designs on just such an application.
++ kevin o'gorman
on pghackers. Arrange for the sort ordering of general INET values
to be network part as major sort key, host part as minor sort key.
I did not force an initdb for this change, but anyone who's running
indexes on general INET values may need to recreate those indexes.
ExecutorRun. This allows LIMIT to work in a view. Also, LIMIT in a
cursor declaration will behave in a reasonable fashion, whereas before
it was overridden by the FETCH count.
MULTIBYTE support is not compiled (you just can't set them to anything
but SQL_ASCII). This should reduce interoperability problems between
MB-enabled clients and non-MB-enabled servers.
support is not present. This allows a non-MB server to load a pg_dumpall
script produced by an MB-enabled server, so long as only ASCII encoding
was used.
