Bruce Momjian [Fri, 11 Jun 2004 03:56:46 +0000 (03:56 +0000)]
The attached tiny patch removes spurious carriage returns that might be
copied by the script that generates psql's help. (You can get the
spurious CRs if you use a CVS client on Windows that does line end
translation.) Elsewhere, the patch should be totally benign.
This removes quite a number of the compile warnings I posted the other
day.
Bruce Momjian [Fri, 11 Jun 2004 03:54:54 +0000 (03:54 +0000)]
>> It certainly doesn't. There still was a bug with the locale stuff,
>> though - the GUC variable was not set in the child
>processes. So "show
>> lc_collate" would *always* return "C", for example. attached
>patch fixes
>> this.
>
>Hm. Why were these vars not propagated by the regular
>mechanism for GUC
>variables (write_nondefault_variables or whatever it's called)? If the
>problem is that it's not accepting PGC_INTERNAL values, then we need to
>fix it there not here, because otherwise we'll have to pass all the
>PGC_INTERNAL variables through the backend_variables file, which seems
>like a recipe for more of the same sort of bug.
Good point :-(
I think the problem is not only that it specifically does not deal with
PGC_INTERNAL variables. The problem is in the fact that
write_nondefault_variables is called *before* the locale is read
(because the locale is read from pg_control and not from any of the
"usual" ways to read it).
Attached patch is another stab at fixing it. It makes postmaster dump a
new copy of the file once it has started the database (before it accepts
any connections), which is when it will know about these parameters.
Also updates the reading code to set the context to the one where the
variable was originally set (PGC_POSTMASTER won't work for PGC_INTERNAL,
and the other way around).
We still pass lc_collate through the special file, because
set_config_option on lc_collate will speficially *not* call setlocale(),
and we need that call. But we no longer call set_config_option from
there.
Bruce Momjian [Fri, 11 Jun 2004 03:48:35 +0000 (03:48 +0000)]
This patch updates pgpipe() on win32 to log exactly which part of the
call fails when it does. (As it is now, there is no way to figure out
the point of error). Shouldn't be a problem since it's most defintily
not a performance-critical path (only called on pgstat startup ATM).
This should help us debug the pipe error message that's on the win32
status page (which I myself have never been able to reproduce, and thus
haven't figured out a better way to debug yet)
Tom Lane [Fri, 11 Jun 2004 01:09:22 +0000 (01:09 +0000)]
When using extended-query protocol, postpone planning of unnamed statements
until Bind is received, so that actual parameter values are visible to the
planner. Make use of the parameter values for estimation purposes (but
don't fold them into the actual plan). This buys back most of the
potential loss of plan quality that ensues from using out-of-line
parameters instead of putting literal values right into the query text.
This patch creates a notion of constant-folding expressions 'for
estimation purposes only', in which case we can be more aggressive than
the normal eval_const_expressions() logic can be. Right now the only
difference in behavior is inserting bound values for Params, but it will
be interesting to look at other possibilities. One that we've seen
come up repeatedly is reducing now() and related functions to current
values, so that queries like ... WHERE timestampcol > now() - '1 day'
have some chance of being planned effectively.
Bruce Momjian [Thu, 10 Jun 2004 22:26:24 +0000 (22:26 +0000)]
Attached is a patch that takes care of the PATHSEP issue. I made a more
extensive change then what was suggested. I found the file path.c that
contained a lot of "Unix/Windows" agnostic functions so I added a function
there instead and removed the PATHSEP declaration in exec.c altogether. All
to keep things from scattering all over the code.
I also took the liberty of changing the name of the functions
"first_path_sep" and "last_path_sep". Where I come from (and I'm apparently
not alone given the former macro name PATHSEP), they should be called
"first_dir_sep" and "last_dir_sep". The new function I introduced, that
actually finds path separators, is now the "first_path_sep". The patch
contains changes on all affected places of course.
I also changed the documentation on dynamic_library_path to reflect the
chagnes.
Tom Lane [Thu, 10 Jun 2004 21:02:00 +0000 (21:02 +0000)]
Adjust cost_nonsequential_access() to have more reasonable behavior
when random_page_cost has a small value. Per Manfred Koizar, though
I didn't use his equation exactly.
Tom Lane [Thu, 10 Jun 2004 18:25:02 +0000 (18:25 +0000)]
Fix oversight in recent ALTER TABLE improvements. We now support
ALTER TABLE tab ADD COLUMN col SERIAL, but we forgot to install the
dependency between the column and the sequence, so the sequence
would not go away if you dropped the table later.
Tom Lane [Thu, 10 Jun 2004 17:56:03 +0000 (17:56 +0000)]
Clean up generation of default names for constraints, indexes, and serial
sequences, as per recent discussion. All these names are now of the
form table_column_type, with digits added if needed to make them unique.
Default constraint names are chosen to be unique across their whole schema,
not just within the parent object, so as to be more SQL-spec-compatible
and make the information schema views more useful.
Tom Lane [Wed, 9 Jun 2004 19:08:20 +0000 (19:08 +0000)]
Support assignment to subfields of composite columns in UPDATE and INSERT.
As a side effect, cause subscripts in INSERT targetlists to do something
more or less sensible; previously we evaluated such subscripts and then
effectively ignored them. Another side effect is that UPDATE-ing an
element or slice of an array value that is NULL now produces a non-null
result, namely an array containing just the assigned-to positions.
Tom Lane [Sun, 6 Jun 2004 22:17:01 +0000 (22:17 +0000)]
Dept of second thoughts: don't use the new wide-character upper/lower
code if we are running in a single-byte encoding. No point in the
extra overhead in that case.
Tom Lane [Sun, 6 Jun 2004 20:30:07 +0000 (20:30 +0000)]
Allow use of table rowtypes directly as column types of other tables.
Instead of prohibiting that, put code into ALTER TABLE to reject ALTERs
that would affect other tables' columns. Eventually we will probably
want to extend ALTER TABLE to actually do something useful here, but
in the meantime it seems wrong to forbid the feature completely just
because ALTER isn't fully baked.
Tom Lane [Sun, 6 Jun 2004 19:07:02 +0000 (19:07 +0000)]
Minor catalog cleanups for composite-type stuff. Adjust signatures shown
in pg_proc for record_in, record_out, etc to reflect that these routines
now make use of the second OID parameter. Remove the ancient SET entry
in pg_type, which is now highly unlikely to ever become used again.
Adjust type_sanity regression test to match.
Tom Lane [Sun, 6 Jun 2004 04:52:55 +0000 (04:52 +0000)]
Remove finger from dike: composite types are now allowed as table columns.
Still a few things to do, like binary I/O and regression tests and docs,
but might as well let people play with the toy.
Tom Lane [Sun, 6 Jun 2004 00:41:28 +0000 (00:41 +0000)]
Infrastructure for I/O of composite types: arrange for the I/O routines
of a composite type to get that type's OID as their second parameter,
in place of typelem which is useless. The actual changes are mostly
centralized in getTypeInputInfo and siblings, but I had to fix a few
places that were fetching pg_type.typelem for themselves instead of
using the lsyscache.c routines. Also, I renamed all the related variables
from 'typelem' to 'typioparam' to discourage people from assuming that
they necessarily contain array element types.
Tom Lane [Sat, 5 Jun 2004 19:48:09 +0000 (19:48 +0000)]
Tweak palloc/repalloc to allow zero bytes to be requested, as per recent
proposal. Eliminate several dozen now-unnecessary hacks to avoid palloc(0).
(It's likely there are more that I didn't find.)
Tom Lane [Sat, 5 Jun 2004 01:55:05 +0000 (01:55 +0000)]
Make the world very nearly safe for composite-type columns in tables.
1. Solve the problem of not having TOAST references hiding inside composite
values by establishing the rule that toasting only goes one level deep:
a tuple can contain toasted fields, but a composite-type datum that is
to be inserted into a tuple cannot. Enforcing this in heap_formtuple
is relatively cheap and it avoids a large increase in the cost of running
the tuptoaster during final storage of a row.
2. Fix some interesting problems in expansion of inherited queries that
reference whole-row variables. We never really did this correctly before,
but it's now relatively painless to solve by expanding the parent's
whole-row Var into a RowExpr() selecting the proper columns from the
child.
If you dike out the preventive check in CheckAttributeType(),
composite-type columns now seem to actually work. However, we surely
cannot ship them like this --- without I/O for composite types, you
can't get pg_dump to dump tables containing them. So a little more
work still to do.
Tom Lane [Fri, 4 Jun 2004 20:35:21 +0000 (20:35 +0000)]
Resurrect heap_deformtuple(), this time implemented as a singly nested
loop over the fields instead of a loop around heap_getattr. This is
considerably faster (O(N) instead of O(N^2)) when there are nulls or
varlena fields, since those prevent use of attcacheoff. Replace loops
over heap_getattr with heap_deformtuple in situations where all or most
of the fields have to be fetched, such as printtup and tuptoaster.
Profiling done more than a year ago shows that this should be a nice
win for situations involving many-column tables.
Bruce Momjian [Fri, 4 Jun 2004 13:30:04 +0000 (13:30 +0000)]
The attached patch will create a dummy pg_config_paths.h. Additionally,
ENABLE_THREAD_SAFETY is supported by the makefile (but not by the
sources, which need some rework)
Tom Lane [Fri, 4 Jun 2004 03:24:04 +0000 (03:24 +0000)]
Remove some long-obsolete code that was causing a strange error message
when someone attempts to create a column of a composite datatype. For
now, just make sure we produce a reasonable error at the 'right place'.
Not sure if this will be made to work before 7.5, but make it act
reasonably in case nothing more gets done.
Tom Lane [Fri, 4 Jun 2004 02:37:06 +0000 (02:37 +0000)]
Support assignment to whole-row variables in plpgsql; also fix glitch
with using a trigger's NEW or OLD record as a whole-row variable in an
expression. Fixes several long-standing complaints.
Tom Lane [Fri, 4 Jun 2004 00:07:52 +0000 (00:07 +0000)]
Allow plpgsql to pass composite-type arguments (ie, whole-row variables)
into SQL expressions. At present this only works usefully for variables
of named rowtypes, not RECORD variables, since the SQL parser can't infer
anything about datatypes from a RECORD Param. Still, it's a step forward.
Tom Lane [Thu, 3 Jun 2004 22:56:43 +0000 (22:56 +0000)]
Restructure plpgsql's parsing of datatype declarations to unify the
scalar and composite (rowtype) cases a little better. This commit is
just a code-beautification operation and shouldn't make any real
difference in behavior, but it's an important preliminary step for
trying to improve plgsql's handling of rowtypes.
Teodor Sigaev [Thu, 3 Jun 2004 12:26:10 +0000 (12:26 +0000)]
- Add aligment of variable data types
- Add aligment for interval data types
- Avoid floating point overflow in penalty functions
Janko Richter <jankorichter@yahoo.de> and teodor
Tom Lane [Thu, 3 Jun 2004 02:08:07 +0000 (02:08 +0000)]
Adjust our timezone library to use pg_time_t (typedef'd as int64) in
place of time_t, as per prior discussion. The behavior does not change
on machines without a 64-bit-int type, but on machines with one, which
is most, we are rid of the bizarre boundary behavior at the edges of
the 32-bit-time_t range (1901 and 2038). The system will now treat
times over the full supported timestamp range as being in your local
time zone. It may seem a little bizarre to consider that times in
4000 BC are PST or EST, but this is surely at least as reasonable as
propagating Gregorian calendar rules back that far.
I did not modify the format of the zic timezone database files, which
means that for the moment the system will not know about daylight-savings
periods outside the range 1901-2038. Given the way the files are set up,
it's not a simple decision like 'widen to 64 bits'; we have to actually
think about the range of years that need to be supported. We should
probably inquire what the plans of the upstream zic people are before
making any decisions of our own.
Bruce Momjian [Thu, 3 Jun 2004 00:25:47 +0000 (00:25 +0000)]
Win32 regression fixes:
. only use the -W flag on pwd for $pkglibdir. All the other paths need
to be seen as MSys type paths, whereas $pkglibdir needs to be expressed
as a genuine windows path.
. run single tests in the background and explicitly wait for them -
solves the problem of the MSys shell not waiting properly for the copy
test to finish.
. use pg_ctl to shut down the test postmaster - no more use of ad hoc
kill programs or the task manager.
Bruce Momjian [Thu, 3 Jun 2004 00:07:38 +0000 (00:07 +0000)]
Add PGETC (for pg_service.conf) and PGLOCALE (for locale dir)
environment variable processing to libpq.
The patch also adds code to our client apps so we set the environment
variable directly based on our binary location, unless it is already
set. This will allow our applications to emit proper locale messages
that are generated in libpq.
Bruce Momjian [Wed, 2 Jun 2004 21:34:49 +0000 (21:34 +0000)]
Small patch that adds some documentation for the area() function.
Specifically, point out that intersecting points in a path will yield
(most likely), unexpected results. Visually these are identical paths,
but mathematically they're not the same. Ex:
area | plan
------
+-----------------------------------------------------------------------
-------------------
-0 | ((0,0),(0,1),(2,1),(2,2),(1,2),(1,0),(0,0))
2 | ((0,0),(0,1),(1,1),(1,2),(2,2),(2,1),(1,1),(1,0),(0,0))
The current algorithm for area(PATH) is very quick, but only handles
non-intersecting paths. I'm going to work on two other functions for
the PATH data type that determines if a PATH is intersecting or not,
and a function that returns the area() for an intersecting PATH. The
intersecting area() function will be considerably slower (I think it's
going to be O(n!) or worse instead of the current O(n), but that comes
with the territory).
Bruce Momjian [Wed, 2 Jun 2004 21:29:29 +0000 (21:29 +0000)]
Per previous discussions, here are two functions to send INT and TERM
(cancel and terminate) signals to other backends. They permit only INT
and TERM, and permits sending only to postgresql backends.
Tom Lane [Wed, 2 Jun 2004 17:28:18 +0000 (17:28 +0000)]
Adjust btree index build to not use shared buffers, thereby avoiding the
locking conflict against concurrent CHECKPOINT that was discussed a few
weeks ago. Also, if not using WAL archiving (which is always true ATM
but won't be if PITR makes it into this release), there's no need to
WAL-log the index build process; it's sufficient to force-fsync the
completed index before commit. This seems to gain about a factor of 2
in my tests, which is consistent with writing half as much data. I did
not try it with WAL on a separate drive though --- probably the gain would
be a lot less in that scenario.
Tom Lane [Tue, 1 Jun 2004 21:49:23 +0000 (21:49 +0000)]
Align GRANT/REVOKE behavior more closely with the SQL spec, per discussion
of bug report #1150. Also, arrange that the object owner's irrevocable
grant-option permissions are handled implicitly by the system rather than
being listed in the ACL as self-granted rights (which was wrong anyway).
I did not take the further step of showing these permissions in an
explicit 'granted by _SYSTEM' ACL entry, as that seemed more likely to
bollix up existing clients than to do anything really useful. It's still
a possible future direction, though.
Tom Lane [Mon, 31 May 2004 20:31:33 +0000 (20:31 +0000)]
Additional mop-up for sync-to-fsync changes: avoid issuing fsyncs for
temp tables, and avoid WAL-logging truncations of temp tables. Do issue
fsync on truncated files (not sure this is necessary but it seems like
a good idea).
Tom Lane [Mon, 31 May 2004 19:24:05 +0000 (19:24 +0000)]
Minor code rationalization: FlushRelationBuffers just returns void,
rather than an error code, and does elog(ERROR) not elog(WARNING)
when it detects a problem. All callers were simply elog(ERROR)'ing on
failure return anyway, and I find it hard to envision a caller that would
not, so we may as well simplify the callers and produce the more useful
error message directly.
Tom Lane [Mon, 31 May 2004 18:31:51 +0000 (18:31 +0000)]
I think I've finally identified the cause of the off-by-one-second
issue in timestamp conversion that we hacked around for so long by
ignoring the seconds field from localtime(). It's simple: you have
to watch out for platform-specific roundoff error when reducing a
possibly-fractional timestamp to integral time_t form. In particular
we should subtract off the already-determined fractional fsec field.
This should be enough to get an exact answer with int64 timestamps;
with float timestamps, throw in a rint() call just to be sure.