aboutsummaryrefslogtreecommitdiff
path: root/src/backend/utils
Commit message (Collapse)AuthorAge
* Make to_timestamp and friends skip leading spaces before an integer field,Tom Lane2009-06-22
| | | | | | | | | | | | | even when not in FM mode. This improves compatibility with Oracle and with our pre-8.4 behavior, as per bug #4862. Brendan Jurd Add a couple of regression test cases for this. In passing, get rid of the labeling of the individual test cases; doesn't seem to be good for anything except causing extra work when inserting a test... Tom Lane
* Revert dubious message wording change.Tom Lane2009-06-22
|
* Message fixesPeter Eisentraut2009-06-21
|
* Fix things so that array_agg_finalfn does not modify or free its inputTom Lane2009-06-20
| | | | | | | ArrayBuildState, per trouble report from Merlin Moncure. By adopting this fix, we are essentially deciding that aggregate final-functions should not modify their inputs ever. Adjust documentation and comments to match that conclusion.
* 8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef listBruce Momjian2009-06-11
| | | | provided by Andrew.
* Fix cash_in() to behave properly in locales where frac_digits is zero,Tom Lane2009-06-10
| | | | | | | eg Japan. Report and fix by Itagaki Takahiro. Also fix CASHDEBUG printout format for branches with 64-bit money type, and some minor comment cleanup. Back-patch to 7.4, because it's broken all the way back.
* Make handling of INTERVAL DAY TO MINUTE and INTERVAL DAY TO SECOND inputTom Lane2009-06-10
| | | | | | | | | | | | more consistent with other cases, by having an unlabeled integer field be treated as a number of minutes or seconds respectively. These cases are outside the spec (which insists on full "dd hh:mm" or "dd hh:mm:ss" input respectively), so it's not much help to us in deciding what to do. But with this change, it's uniformly the case that an unlabeled integer will be considered as being a number of the interval's rightmost field. The change also takes us back to the 8.3 behavior of throwing error for certain ambiguous inputs such as INTERVAL '1 2' DAY TO MINUTE. Per recent discussion.
* Ensure xmlFree(NULL) is a no-op instead of a core dump. Per report fromTom Lane2009-06-10
| | | | | | | | | Sergey Burladyan, there are at least some dank corners of libxml2 that assume this behavior, even though their published documentation suggests they shouldn't. This is only really a live problem in 8.3, but the code is still there for possible debugging use in HEAD, so patch both branches.
* Fix xmlattribute escaping XML special characters twice (bug #4822).Peter Eisentraut2009-06-09
| | | | Author: Itagaki Takahiro <itagaki.takahiro@oss.ntt.co.jp>
* Switch order of tests to avoid possible Assert failure forTom Lane2009-06-09
| | | | | | "array_agg_finalfn(null)". We should modify pg_proc entries to prevent this query from being accepted, but let's just make the function itself secure too. Per my note of today.
* Fix failure to double-quote function argument names when needed, inTom Lane2009-06-09
| | | | | pg_get_function_arguments() and related functions. Per report from Andreas Nolte.
* Fix map_sql_table_to_xmlschema() with dropped attributes.Peter Eisentraut2009-06-08
| | | | also backpatched to 8.3
* Improve the recently-added support for properly pluralized error messagesTom Lane2009-06-04
| | | | | | | | | | by extending the ereport() API to cater for pluralization directly. This is better than the original method of calling ngettext outside the elog.c code because (1) it avoids double translation, which wastes cycles and in the worst case could give a wrong result; and (2) it avoids having to use a different coding method in PL code than in the core backend. The client-side uses of ngettext are not touched since neither of these concerns is very pressing in the client environment. Per my proposal of yesterday.
* Change AdjustIntervalForTypmod to not discard higher-order field values on theTom Lane2009-06-01
| | | | | | | | | | | | | | | | | | | | | | | | | | grounds that they don't fit into the specified interval qualifier (typmod). This behavior, while of long standing, is clearly wrong per spec --- for example the value INTERVAL '999' SECOND means 999 seconds and should not be reduced to less than 60 seconds. In some cases there could be grounds to raise an error if higher-order field values are not given as zero; for example '1 year 1 month'::INTERVAL MONTH should arguably be taken as an error rather than equivalent to 13 months. However our internal representation doesn't allow us to do that in a fashion that would consistently reject all and only the cases that a strict reading of the spec would suggest. Also, seeing that for example INTERVAL '13' MONTH will print out as '1 year 1 mon', we have to be careful not to create a situation where valid data will fail to dump and reload. The present patch therefore takes the attitude of not throwing an error in any such case. We might want to revisit that in future but it would take more redesign than seems prudent in late beta. Per a complaint from Sebastien Flaesch and subsequent discussion. While at other times we might have just postponed such an issue to the next development cycle, 8.4 already has changed the parsing of interval literals quite a bit in an effort to accept all spec-compliant cases correctly. This seems like a change that should be part of that rather than coming along later.
* Fix DecodeInterval to report an error for multiple occurrences of DAY, WEEK,Tom Lane2009-06-01
| | | | | | | | | | | YEAR, DECADE, CENTURY, or MILLENIUM fields, just as it always has done for other types of fields. The previous behavior seems to have been a hack to avoid defining bit-positions for all these field types in DTK_M() masks, rather than something that was really considered to be desired behavior. But there is room in the masks for these, and we really need to tighten up at least the behavior of DAY and YEAR fields to avoid unexpected behavior associated with the 8.4 changes to interpret ambiguous fields based on the interval qualifier (typmod) value. Per my example and proposed patch.
* Fix compiler warnings on Sun Studio of the sortPeter Eisentraut2009-05-27
| | | | | | "tsquery_op.c", line 193: warning: syntax error: empty declaration Zdenek Kotala
* Allow the second argument of pg_get_expr() to be just zero when deparsingTom Lane2009-05-26
| | | | | | | an expression that's not supposed to contain variables. Per discussion with Gevik Babakhani, this eliminates the need for an ugly kluge (namely, specifying some unrelated relation name). Remove one such kluge from pg_dump.
* Remove the useless and rather inconsistent return values of EncodeDateOnly,Tom Lane2009-05-26
| | | | | EncodeTimeOnly, EncodeDateTime, EncodeInterval. These don't have any good reason to fail, and their callers were mostly not checking anyway.
* Add range checks to time_recv() and timetz_recv(), to prevent binary inputTom Lane2009-05-26
| | | | | | | | of time values that would not be accepted via textual input. Per gripe from Andrew McNamara. This is potentially a back-patchable bug fix, but for the moment it doesn't seem sufficiently high impact to justify doing that.
* Fix LIKE's special-case code for % followed by _. I'm not entirely sure thatTom Lane2009-05-24
| | | | | | | | | | | this case is worth a special code path, but a special code path that gets the boundary condition wrong is definitely no good. Per bug #4821 from Andrew Gierth. In passing, clean up some minor code formatting issues (excess parentheses and blank lines in odd places). Back-patch to 8.3, where the bug was introduced.
* Resort tsvector's lexemes in tsvectorrecv instead of emmiting an error.Teodor Sigaev2009-05-21
| | | | | | | Basically, it's needed to support binary dump from 8.3 because ordering rule was changed. Per discussion with Bruce.
* Removed comparison of unsigned expression < 0.Michael Meskes2009-05-21
|
* Rewrite xml.c's memory management (yet again). Give up on the idea ofTom Lane2009-05-13
| | | | | | | | | | | | | | | | | | | | | | redirecting libxml's allocations into a Postgres context. Instead, just let it use malloc directly, and add PG_TRY blocks as needed to be sure we release libxml data structures in error recovery code paths. This is ugly but seems much more likely to play nicely with third-party uses of libxml, as seen in recent trouble reports about using Perl XML facilities in pl/perl and bug #4774 about contrib/xml2. I left the code for allocation redirection in place, but it's only built/used if you #define USE_LIBXMLCONTEXT. This is because I found it useful to corral libxml's allocations in a palloc context when hunting for libxml memory leaks, and we're surely going to have more of those in the future with this type of approach. But we don't want it turned on in a normal build because it breaks exactly what we need to fix. I have not re-indented most of the code sections that are now wrapped by PG_TRY(); that's for ease of review. pg_indent will fix it. This is a pre-existing bug in 8.3, but I don't dare back-patch this change until it's gotten a reasonable amount of field testing.
* Fix intratransaction memory leaks in xml_recv, xmlconcat, xmlroot, andTom Lane2009-05-12
| | | | | | | | | | | | | | | xml_parse, all arising from the same sloppy usage of parse_xml_decl. The original coding had that function returning its output string parameters in the libxml context, which is long-lived, and all but one of its callers neglected to free the strings afterwards. The easiest and most bulletproof fix is to return the strings in the local palloc context instead, since that's short-lived. This was only costing a dozen or two bytes per function call, but that adds up fast if the function is called repeatedly ... Noted while poking at the more general problem of what to do with our libxml memory allocation hooks. Back-patch to 8.3, which has the identical coding.
* Install a "dead man switch" to allow the postmaster to detect cases whereTom Lane2009-05-05
| | | | | | | | | | | | | | | | | | | | | | | | | | a backend has done exit(0) or exit(1) without having disengaged itself from shared memory. We are at risk for this whenever third-party code is loaded into a backend, since such code might not know it's supposed to go through proc_exit() instead. Also, it is reported that under Windows there are ways to externally kill a process that cause the status code returned to the postmaster to be indistinguishable from a voluntary exit (thank you, Microsoft). If this does happen then the system is probably hosed --- for instance, the dead session might still be holding locks. So the best recovery method is to treat this like a backend crash. The dead man switch is armed for a particular child process when it acquires a regular PGPROC, and disarmed when the PGPROC is released; these should be the first and last touches of shared memory resources in a backend, or close enough anyway. This choice means there is no coverage for auxiliary processes, but I doubt we need that, since they shouldn't be executing any user-provided code anyway. This patch also improves the management of the EXEC_BACKEND ShmemBackendArray array a bit, by reducing search costs. Although this problem is of long standing, the lack of field complaints seems to mean it's not critical enough to risk back-patching; at least not till we get some more testing of this mechanism.
* Fix assign_pgstat_temp_directory() to ensure the directory path isTom Lane2009-05-03
| | | | canonicalized. Avoid the need to elog(FATAL) on out-of-memory.
* Update UTF-8 <--> EUC_KR, JOHAB, UHC mappings.Tatsuo Ishii2009-05-03
| | | | Patch contributed by Chuck McDevitt
* Install some simple defenses in postmaster startup to help ensure a usefulTom Lane2009-05-02
| | | | | | | | | | | | error message if the installation directory layout is messed up (or at least, something more useful than the behavior exhibited in bug #4787). During postmaster startup, check that get_pkglib_path resolves as a readable directory; and if ParseTzFile() fails to open the expected timezone abbreviation file, check the possibility that the directory is missing rather than just the specified file. In case of either failure, issue a hint suggesting that the installation is broken. These two checks cover the lib/ and share/ trees of a full installation, which should take care of most scenarios where a sysadmin decides to get cute.
* When checking for datetime field overflow, we should allow a fractional-secondTom Lane2009-05-01
| | | | | | | | | | | | | | part that rounds up to exactly 1.0 second. The previous coding rejected input like "00:12:57.9999999999999999999999999999", with the exact number of nines needed to cause failure varying depending on float-timestamp option and possibly on platform. Obviously this should round up to the next integral second, if we don't have enough precision to distinguish the value from that. Per bug #4789 from Robert Kruus. In passing, fix a missed check for fractional seconds in one copy of the "is it greater than 24:00:00" code. Broken all the way back, so patch all the way back.
* Move gettext encoding names into encnames.c, so we only have one place to ↵Magnus Hagander2009-04-24
| | | | | | update. Per discussion.
* varstr_cmp and any comparison function that piggybacks on it can returnHeikki Linnakangas2009-04-23
| | | | | | | any negative or positive number, not just -1 or 1. Fix comment on varstr_cmp and citext test case accordingly. As pointed out by Zdenek Kotala, and buildfarm member gothic moth.
* Change the default value of max_prepared_transactions to zero, and addTom Lane2009-04-23
| | | | | | | | | | | | | | | | | | | | documentation warnings against setting it nonzero unless active use of prepared transactions is intended and a suitable transaction manager has been installed. This should help to prevent the type of scenario we've seen several times now where a prepared transaction is forgotten and eventually causes severe maintenance problems (or even anti-wraparound shutdown). The only real reason we had the default be nonzero in the first place was to support regression testing of the feature. To still be able to do that, tweak pg_regress to force a nonzero value during "make check". Since we cannot force a nonzero value in "make installcheck", add a variant regression test "expected" file that shows the results that will be obtained when max_prepared_transactions is zero. Also, extend the HINT messages for transaction wraparound warnings to mention the possibility that old prepared transactions are causing the problem. All per today's discussion.
* Fix estimate_num_groups() to not fail on PlaceHolderVars, per report fromTom Lane2009-04-19
| | | | | | | | | Stefan Kaltenbrunner. The most reasonable behavior (at least for the near term) seems to be to ignore the PlaceHolderVar and examine its argument instead. In support of this, change the API of pull_var_clause() to allow callers to request recursion into PlaceHolderVars. Currently estimate_num_groups() is the only customer for that behavior, but where there's one there may be others.
* Substitute extraneous underscores with spaces.Alvaro Herrera2009-04-15
|
* Remove SQL-compatibility function cardinality(). It is not exactly clearTom Lane2009-04-09
| | | | | | | how this ought to behave for multi-dimensional arrays. Per discussion, not having it at all seems better than having it with what might prove to be the wrong behavior. We can always add it later when we have consensus on the correct behavior.
* Treat EOF like \n for line-counting purposes in ParseConfigFile,Tom Lane2009-04-09
| | | | per bug #4752. Fujii Masao
* Allow leading and trailing spaces around NaN in numeric_in.Tom Lane2009-04-08
| | | | Sam Mason, rewritten a bit by Tom.
* XMLATTRIBUTES() should send the attribute values throughPeter Eisentraut2009-04-08
| | | | | map_sql_value_to_xml_value() instead of directly through the data type output function. This is per SQL standard, and consistent with XMLELEMENT().
* Oops, mustn't call textdomain() when compiling without --enable-nlsHeikki Linnakangas2009-04-08
|
* Tell gettext which codeset to use by calling bind_textdomain_codeset(). WeHeikki Linnakangas2009-04-08
| | | | | | | | | already did that on Windows, but it's needed on other platforms too when LC_CTYPE=C. With other locales, we enforce (or trust) that the codeset of the locale matches the server encoding so we don't need to bind it explicitly. It should do no harm in that case either, but I don't have full faith in the PG encoding -> OS codeset mapping table yet. Per recent discussion on pgsql-hackers.
* Revert addition of units to GUC descriptions; doesn't affectBruce Momjian2009-04-07
| | | | postgresql.conf.
* More GUC units doc updates.Bruce Momjian2009-04-07
| | | | Euler Taveira de Oliveira
* Add unit documentation for various postgresql.conf settings.Bruce Momjian2009-04-06
|
* Add entry in the encoding number to OS name table for KOI8-U.Peter Eisentraut2009-04-06
|
* Properly align equals signs in new postgresql.conf units comments.Bruce Momjian2009-04-06
|
* Document in postgresql.conf that the default units forBruce Momjian2009-04-06
| | | | log_min_duration_statement is milliseconds.
* Display postgresql.conf unit options in an easier-to-understand,Bruce Momjian2009-04-06
| | | | 2-column format.
* Change cardinality() into a C-code function, instead of a SQL-languageTom Lane2009-04-05
| | | | | | | alias for array_length(v,1). The efficiency gain here is doubtless negligible --- what I'm interested in is making sure that if we have second thoughts about the definition, we will not have to force a post-beta initdb to change the implementation.
* Change EXPLAIN output so that subplans and initplans (particularly CTEs)Tom Lane2009-04-05
| | | | | | | | | | | are individually labeled, rather than just grouped under an "InitPlan" or "SubPlan" heading. This in turn makes it possible for decompilation of a subplan reference to usefully identify which subplan it's referencing. I also made InitPlans identify which parameter symbol(s) they compute, so that references to those parameters elsewhere in the plan tree can be connected to the initplan that will be executed. Per a gripe from Robert Haas about EXPLAIN output of a WITH query being inadequate, plus some longstanding pet peeves of my own.
* Rewrite interval_hash() so that the hashcodes are equal for values thatTom Lane2009-04-04
| | | | | | | | | | | | | | | interval_eq() considers equal. I'm not sure how that fundamental requirement escaped us through multiple revisions of this hash function, but there it is; it's been wrong since interval_hash was first written for PG 7.1. Per bug #4748 from Roman Kononov. Backpatch to all supported releases. This patch changes the contents of hash indexes for interval columns. That's no particular problem for PG 8.4, since we've broken on-disk compatibility of hash indexes already; but it will require a migration warning note in the next minor releases of all existing branches: "if you have any hash indexes on columns of type interval, REINDEX them after updating".
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-07 15:09:52 +0000