summaryrefslogtreecommitdiff
path: root/contrib/xml2/xpath.c
Commit message (Collapse)AuthorAgeFilesLines
* Rename SetSingleFuncCall() to InitMaterializedSRF()Michael Paquier2022-10-181-1/+1
| | | | | | | | | | | | | | | | | | Per discussion, the existing routine name able to initialize a SRF function with materialize mode is unpopular, so rename it. Equally, the flags of this function are renamed, as of: - SRF_SINGLE_USE_EXPECTED -> MAT_SRF_USE_EXPECTED_DESC - SRF_SINGLE_BLESS -> MAT_SRF_BLESS The previous function and flags introduced in 9e98583 are kept around for compatibility purposes, so as any extension code already compiled with v15 continues to work as-is. The declarations introduced here for compatibility will be removed from HEAD in a follow-up commit. The new names have been suggested by Andres Freund and Melanie Plageman. Discussion: https://postgr.es/m/20221013194820.ciktb2sbbpw7cljm@awork3.anarazel.de Backpatch-through: 15
* Simplify SRFs using materialize mode in contrib/ modulesMichael Paquier2022-03-081-62/+10
| | | | | | | | | | | | | | | | | | | | | 9e98583 introduced a helper to centralize building their needed state (tuplestore, tuple descriptors, etc.), checking for any errors. This commit updates all places of contrib/ that can be switched to use SetSingleFuncCall() as a drop-in replacement, resulting in the removal of a lot of boilerplate code in all the modules updated by this commit. Per analysis, some places remain as they are: - pg_logdir_ls() in adminpack/ uses historically TYPEFUNC_RECORD as return type, and I suspect that changing it may cause issues at run-time with some of its past versions, down to 1.0. - dblink/ uses a wrapper function doing exactly the work of SetSingleFuncCall(). Here the switch should be possible, but rather invasive so it does not seem the extra backpatch maintenance cost. - tablefunc/, similarly, uses multiple helper functions with portions of SetSingleFuncCall() spread across the code paths of this module. Author: Melanie Plageman Discussion: https://postgr.es/m/CAAKRu_bvDPJoL9mH6eYwvBpPtTGQwbDzfJbCM-OjkSZDu5yTPg@mail.gmail.com
* Remove all traces of tuplestore_donestoring() in the C codeMichael Paquier2022-02-171-2/+0
| | | | | | | | | | | | | | | | | | This routine is a no-op since dd04e95 from 2003, with a macro kept around for compatibility purposes. This has led to the same code patterns being copy-pasted around for no effect, sometimes in confusing ways like in pg_logical_slot_get_changes_guts() from logical.c where the code was actually incorrect. This issue has been discussed on two different threads recently, so rather than living with this legacy, remove any uses of this routine in the C code to simplify things. The compatibility macro is kept to avoid breaking any out-of-core modules that depend on it. Reported-by: Tatsuhito Kasahara, Justin Pryzby Author: Tatsuhito Kasahara Discussion: https://postgr.es/m/20211217200419.GQ17618@telsasoft.com Discussion: https://postgr.es/m/CAP0=ZVJeeYfAeRfmzqAF2Lumdiv4S4FewyBnZd4DPTrsSQKJKw@mail.gmail.com
* Delete contrib/xml2's legacy implementation of xml_is_well_formed().Tom Lane2022-02-141-45/+0
| | | | | | | | | | | | | | | | | This function is unreferenced in modern usage; it was superseded in 9.1 by a core function of the same name. It has been left in place in the C code only so that pre-9.1 SQL definitions of the contrib/xml2 functions would continue to work. Eleven years seems like enough time for people to have updated to the extension-style version of the xml2 module, so let's drop this. We did this once before, in 20540710e, and then reverted it because the intended change of PGDLLEXPORT markings didn't happen. This time the reason is to suppress link-time duplicate-symbol warnings on AIX. That's not worth a lot perhaps, but the value of keeping this function has surely dropped to about zero by now. Discussion: https://postgr.es/m/2717731.1644778752@sss.pgh.pa.us
* Phase 2 pgindent run for v12.Tom Lane2019-05-221-4/+4
| | | | | | | | | Switch to 2.1 version of pg_bsd_indent. This formats multiline function declarations "correctly", that is with additional lines of parameter declarations indented to match where the first line's left parenthesis is. Discussion: https://postgr.es/m/CAEepm=0P3FeTXRcU5B2W3jv3PgRVZ-kGUXLGfd42FFhUROO3ug@mail.gmail.com
* Phase 3 of pgindent updates.Tom Lane2017-06-211-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | Don't move parenthesized lines to the left, even if that means they flow past the right margin. By default, BSD indent lines up statement continuation lines that are within parentheses so that they start just to the right of the preceding left parenthesis. However, traditionally, if that resulted in the continuation line extending to the right of the desired right margin, then indent would push it left just far enough to not overrun the margin, if it could do so without making the continuation line start to the left of the current statement indent. That makes for a weird mix of indentations unless one has been completely rigid about never violating the 80-column limit. This behavior has been pretty universally panned by Postgres developers. Hence, disable it with indent's new -lpl switch, so that parenthesized lines are always lined up with the preceding left paren. This patch is much less interesting than the first round of indent changes, but also bulkier, so I thought it best to separate the effects. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
* Phase 2 of pgindent updates.Tom Lane2017-06-211-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change pg_bsd_indent to follow upstream rules for placement of comments to the right of code, and remove pgindent hack that caused comments following #endif to not obey the general rule. Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using the published version of pg_bsd_indent, but a hacked-up version that tried to minimize the amount of movement of comments to the right of code. The situation of interest is where such a comment has to be moved to the right of its default placement at column 33 because there's code there. BSD indent has always moved right in units of tab stops in such cases --- but in the previous incarnation, indent was working in 8-space tab stops, while now it knows we use 4-space tabs. So the net result is that in about half the cases, such comments are placed one tab stop left of before. This is better all around: it leaves more room on the line for comment text, and it means that in such cases the comment uniformly starts at the next 4-space tab stop after the code, rather than sometimes one and sometimes two tabs after. Also, ensure that comments following #endif are indented the same as comments following other preprocessor commands such as #else. That inconsistency turns out to have been self-inflicted damage from a poorly-thought-through post-indent "fixup" in pgindent. This patch is much less interesting than the first round of indent changes, but also bulkier, so I thought it best to separate the effects. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
* Initial pgindent run with pg_bsd_indent version 2.0.Tom Lane2017-06-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The new indent version includes numerous fixes thanks to Piotr Stefaniak. The main changes visible in this commit are: * Nicer formatting of function-pointer declarations. * No longer unexpectedly removes spaces in expressions using casts, sizeof, or offsetof. * No longer wants to add a space in "struct structname *varname", as well as some similar cases for const- or volatile-qualified pointers. * Declarations using PG_USED_FOR_ASSERTS_ONLY are formatted more nicely. * Fixes bug where comments following declarations were sometimes placed with no space separating them from the code. * Fixes some odd decisions for comments following case labels. * Fixes some cases where comments following code were indented to less than the expected column 33. On the less good side, it now tends to put more whitespace around typedef names that are not listed in typedefs.list. This might encourage us to put more effort into typedef name collection; it's not really a bug in indent itself. There are more changes coming after this round, having to do with comment indentation and alignment of lines appearing within parentheses. I wanted to limit the size of the diffs to something that could be reviewed without one's eyes completely glazing over, so it seemed better to split up the changes as much as practical. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
* Use wrappers of PG_DETOAST_DATUM_PACKED() more.Noah Misch2017-03-121-21/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | This makes almost all core code follow the policy introduced in the previous commit. Specific decisions: - Text search support functions with char* and length arguments, such as prsstart and lexize, may receive unaligned strings. I doubt maintainers of non-core text search code will notice. - Use plain VARDATA() on values detoasted or synthesized earlier in the same function. Use VARDATA_ANY() on varlenas sourced outside the function, even if they happen to always have four-byte headers. As an exception, retain the universal practice of using VARDATA() on return values of SendFunctionCall(). - Retain PG_GETARG_BYTEA_P() in pageinspect. (Page images are too large for a one-byte header, so this misses no optimization.) Sites that do not call get_page_from_raw() typically need the four-byte alignment. - For now, do not change btree_gist. Its use of four-byte headers in memory is partly entangled with storage of 4-byte headers inside GBT_VARKEY, on disk. - For now, do not change gtrgm_consistent() or gtrgm_distance(). They incorporate the varlena header into a cache, and there are multiple credible implementation strategies to consider.
* Fix typos in comments.Heikki Linnakangas2017-02-061-1/+1
| | | | | | | | | Backpatch to all supported versions, where applicable, to make backpatching of future fixes go more smoothly. Josh Soref Discussion: https://www.postgresql.org/message-id/CACZqfqCf+5qRztLPgmmosr-B0Ye4srWzzw_mo4c_8_B_mtjmJQ@mail.gmail.com
* Revert "Delete contrib/xml2's legacy implementation of xml_is_well_formed()."Tom Lane2016-11-071-0/+45
| | | | | | | This partly reverts commit 20540710e83f2873707c284a0c0693f0b57156c4. Since we've given up on adding PGDLLEXPORT markers to PG_FUNCTION_INFO_V1, there's no need to remove the legacy compatibility function. I kept the documentation changes, though, as they seem appropriate anyway.
* Delete contrib/xml2's legacy implementation of xml_is_well_formed().Tom Lane2016-11-041-45/+0
| | | | | | | | | | | | | | | | | | | | | | | | | This function is unreferenced in modern usage; it was superseded in 9.1 by a core function of the same name. It has been left in place in the C code only so that pre-9.1 SQL definitions of the contrib/xml2 functions would continue to work. Six years seems like enough time for people to have updated to the extension-style version of the xml2 module, so let's drop this. The key reason for not keeping it any longer is that we want to stick an explicit PGDLLEXPORT into PG_FUNCTION_INFO_V1(), and the similarity of name to the core function creates a conflict that compilers will complain about. Extracted from a larger patch for that purpose. I'm committing this change separately to give it more visibility in the commit logs. While at it, remove the documentation entry that claimed that xml_is_well_formed() is a function provided by contrib/xml2, and instead mention the even more ancient alias xml_valid(). Laurenz Albe, doc change by me Patch: <A737B7A37273E048B164557ADEF4A58B53962ED8@ntex2010a.host.magwien.gv.at>
* Widen query numbers-of-tuples-processed counters to uint64.Tom Lane2016-03-121-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | This patch widens SPI_processed, EState's es_processed field, PortalData's portalPos field, FuncCallContext's call_cntr and max_calls fields, ExecutorRun's count argument, PortalRunFetch's result, and the max number of rows in a SPITupleTable to uint64, and deals with (I hope) all the ensuing fallout. Some of these values were declared uint32 before, and others "long". I also removed PortalData's posOverflow field, since that logic seems pretty useless given that portalPos is now always 64 bits. The user-visible results are that command tags for SELECT etc will correctly report tuple counts larger than 4G, as will plpgsql's GET GET DIAGNOSTICS ... ROW_COUNT command. Queries processing more tuples than that are still not exactly the norm, but they're becoming more common. Most values associated with FETCH/MOVE distances, such as PortalRun's count argument and the count argument of most SPI functions that have one, remain declared as "long". It's not clear whether it would be worth promoting those to int64; but it would definitely be a large dollop of additional API churn on top of this, and it would only help 32-bit platforms which seem relatively less likely to see any benefit. Andreas Scherbaum, reviewed by Christian Ullrich, additional hacking by me
* Replace a bunch more uses of strncpy() with safer coding.Tom Lane2015-01-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | strncpy() has a well-deserved reputation for being unsafe, so make an effort to get rid of nearly all occurrences in HEAD. A large fraction of the remaining uses were passing length less than or equal to the known strlen() of the source, in which case no null-padding can occur and the behavior is equivalent to memcpy(), though doubtless slower and certainly harder to reason about. So just use memcpy() in these cases. In other cases, use either StrNCpy() or strlcpy() as appropriate (depending on whether padding to the full length of the destination buffer seems useful). I left a few strncpy() calls alone in the src/timezone/ code, to keep it in sync with upstream (the IANA tzcode distribution). There are also a few such calls in ecpg that could possibly do with more analysis. AFAICT, none of these changes are more than cosmetic, except for the four occurrences in fe-secure-openssl.c, which are in fact buggy: an overlength source leads to a non-null-terminated destination buffer and ensuing misbehavior. These don't seem like security issues, first because no stack clobber is possible and second because if your values of sslcert etc are coming from untrusted sources then you've got problems way worse than this. Still, it's undesirable to have unpredictable behavior for overlength inputs, so back-patch those four changes to all active branches.
* Adjust blank lines around PG_MODULE_MAGIC defines, for consistencyBruce Momjian2014-07-101-1/+0
| | | | Report by Robert Haas
* pgindent run for 9.4Bruce Momjian2014-05-061-1/+1
| | | | | This includes removing tabs after periods in C comments, which was applied to back branches, so this change should not effect backpatching.
* Create function prototype as part of PG_FUNCTION_INFO_V1 macroPeter Eisentraut2014-04-181-11/+0
| | | | | | | | | | | | | | | | | Because of gcc -Wmissing-prototypes, all functions in dynamically loadable modules must have a separate prototype declaration. This is meant to detect global functions that are not declared in header files, but in cases where the function is called via dfmgr, this is redundant. Besides filling up space with boilerplate, this is a frequent source of compiler warnings in extension modules. We can fix that by creating the function prototype as part of the PG_FUNCTION_INFO_V1 macro, which such modules have to use anyway. That makes the code of modules cleaner, because there is one less place where the entry points have to be listed, and creates an additional check that functions have the right prototype. Remove now redundant prototypes from contrib and other modules.
* Split tuple struct defs from htup.h to htup_details.hAlvaro Herrera2012-08-301-0/+1
| | | | | | | | | | | | This reduces unnecessary exposure of other headers through htup.h, which is very widely included by many files. I have chosen to move the function prototypes to the new file as well, because that means htup.h no longer needs to include tupdesc.h. In itself this doesn't have much effect in indirect inclusion of tupdesc.h throughout the tree, because it's also required by execnodes.h; but it's something to explore in the future, and it seemed best to do the htup.h change now while I'm busy with it.
* Run pgindent on 9.2 source tree in preparation for first 9.3Bruce Momjian2012-06-101-107/+107
| | | | commit-fest.
* Rewrite libxml error handling to be more robust.Tom Lane2011-07-201-38/+93
| | | | | | | | | | | | | | | | | | | | | libxml reports some errors (like invalid xmlns attributes) via the error handler hook, but still returns a success indicator to the library caller. This causes us to miss some errors that are important to report. Since the "generic" error handler hook doesn't know whether the message it's getting is for an error, warning, or notice, stop using that and instead start using the "structured" error handler hook, which gets enough information to be useful. While at it, arrange to save and restore the error handler hook setting in each libxml-using function, rather than assuming we can set and forget the hook. This should improve the odds of working nicely with third-party libraries that also use libxml. In passing, volatile-ize some local variables that get modified within PG_TRY blocks. I noticed this while testing with an older gcc version than I'd previously tried to compile xml.c with. Florian Pflug and Tom Lane, with extensive review/testing by Noah Misch
* pgindent run before PG 9.1 beta 1.Bruce Momjian2011-04-101-6/+6
|
* Fix significant memory leak in contrib/xml2 functions.Tom Lane2010-11-261-72/+90
| | | | | | | | | Most of the functions that execute XPath queries leaked the data structures created by libxml2. This memory would not be recovered until end of session, so it mounts up pretty quickly in any serious use of the feature. Per report from Pavel Stehule, though this isn't his patch. Back-patch to all supported branches.
* Remove cvs keywords from all files.Magnus Hagander2010-09-201-1/+1
|
* Add xml_is_well_formed, xml_is_well_formed_document, xml_is_well_formed_contentTom Lane2010-08-131-2/+9
| | | | | | | | functions to the core XML code. Per discussion, the former depends on XMLOPTION while the others do not. These supersede a version previously offered by contrib/xml2. Mike Fowler, reviewed by Pavel Stehule
* pgindent run for 9.0, second runBruce Momjian2010-07-061-3/+3
|
* Make contrib/xml2 use core xml.c's error handler, when available (that is,Tom Lane2010-03-031-73/+11
| | | | | | | | | | | | | in versions >= 8.3). The core code is more robust and efficient than what was there before, and this also reduces risks involved in swapping different libxml error handler settings. Before 8.3, there is still some risk of problems if add-on modules such as Perl invoke libxml without setting their own error handler. Given the lack of reports I'm not sure there's a risk in practice, so I didn't take the step of actually duplicating the core code into older contrib/xml2 branches. Instead I just tweaked the existing code to ensure it didn't leave a dangling pointer to short-lived memory when throwing an error.
* Remove xmlCleanupParser calls from contrib/xml2.Tom Lane2010-03-011-30/+5
| | | | | | | These are unnecessary and probably dangerous. I don't see any immediate risk situations in the core XML support or contrib/xml2 itself, but there could be issues with external uses of libxml2, and in any case it's an accident waiting to happen.
* Fix up memory management problems in contrib/xml2.Tom Lane2010-02-281-56/+22
| | | | | | | | | | | | | | | | | | | | | Get rid of the code that attempted to funnel libxml2's memory allocations into palloc. We already knew from experience with the core xml datatype that trying to do this is simply not reliable. Unlike the core code, I did not bother adding a lot of PG_TRY/PG_CATCH logic to try to ensure that everything is cleaned up on error exit. Hence, we might leak some memory if one of these functions fails partway through. Given the deprecated status of this contrib module and the fact that errors partway through the functions shouldn't be too common, it doesn't seem worth worrying about. Also fix a separate bug in xpath_table, that it did the wrong things if given a result tuple descriptor with less than 2 columns. While such a case isn't very useful in practice, we shouldn't fail or stomp memory when it occurs. Add some simple regression tests based on all the reported crash cases that I have on hand. This should be back-patched, but let's see if the buildfarm likes it first.
* Assorted code cleanup for contrib/xml2. No change in functionality,Tom Lane2010-02-281-160/+124
| | | | just make it a bit less ugly in places.
* Silence compiler warning, noted by Stefan KaltenbrunnerMagnus Hagander2010-01-171-2/+2
|
* Previous fix for temporary file management broke returning a set fromHeikki Linnakangas2009-12-291-5/+1
| | | | | | | | | | | | | | PL/pgSQL function within an exception handler. Make sure we use the right resource owner when we create the tuplestore to hold returned tuples. Simplify tuplestore API so that the caller doesn't need to be in the right memory context when calling tuplestore_put* functions. tuplestore.c automatically switches to the memory context used when the tuplestore was created. Tuplesort was already modified like this earlier. This patch also removes the now useless MemoryContextSwitch calls from callers. Report by Aleksei on pgsql-bugs on Dec 22 2009. Backpatch to 8.1, like the previous patch that broke this.
* 8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef listBruce Momjian2009-06-111-15/+15
| | | | provided by Andrew.
* Fix executor/spi.h to follow our usual conventions for include files, ie,Tom Lane2009-01-071-5/+7
| | | | | | | | | not include postgres.h nor anything else it doesn't directly need. Add #includes to calling files as needed to compensate. Per my proposal of yesterday. This should be noted as a source code change in the 8.4 release notes, since it's likely to require changes in add-on modules.
* Be more tense about not creating tuplestores with randomAccess = true unlessTom Lane2008-10-291-2/+4
| | | | | | | | backwards scan could actually happen. In particular, pass a flag to materialize-mode SRFs that tells them whether they need to require random access. In passing, also suppress unneeded backward-scan overhead for a Portal's holdStore tuplestore. Per my proposal about reducing I/O costs for tuplestores.
* Add $PostgreSQL$ markers to a lot of files that were missing them.Andrew Dunstan2008-05-171-1/+4
| | | | | | | | | | This particular batch was just for *.c and *.h file. The changes were made with the following 2 commands: find . \( \( -name 'libstemmer' -o -name 'expected' -o -name 'ppport.h' \) -prune \) -o \( -name '*.[ch]' \) \( -exec grep -q '\$PostgreSQL' {} \; -o -print \) | while read file ; do head -n 1 < $file | grep -q '^/\*' && echo $file; done | xargs -l sed -i -e '1s/^\// /' -e '1i/*\n * $PostgreSQL:$ \n *' find . \( \( -name 'libstemmer' -o -name 'expected' -o -name 'ppport.h' \) -prune \) -o \( -name '*.[ch]' \) \( -exec grep -q '\$PostgreSQL' {} \; -o -print \) | xargs -l sed -i -e '1i/*\n * $PostgreSQL:$ \n */'
* Use new cstring/text conversion functions in some additional places.Tom Lane2008-05-041-18/+3
| | | | | | | | These changes assume that the varchar and xml data types are represented the same as text. (I did not, however, accept the portions of the proposed patch that wanted to assume bytea is the same as text --- tgl.) Brendan Jurd
* Fix core dump in contrib/xml2's xpath_table() when the input query returnsTom Lane2008-03-261-7/+10
| | | | a NULL value. Per bug #4058.
* Simplify and standardize conversions between TEXT datums and ordinary CTom Lane2008-03-251-10/+5
| | | | | | | | | | | | | | | | | | | | strings. This patch introduces four support functions cstring_to_text, cstring_to_text_with_len, text_to_cstring, and text_to_cstring_buffer, and two macros CStringGetTextDatum and TextDatumGetCString. A number of existing macros that provided variants on these themes were removed. Most of the places that need to make such conversions now require just one function or macro call, in place of the multiple notational layers that used to be needed. There are no longer any direct calls of textout or textin, and we got most of the places that were using handmade conversions via memcpy (there may be a few still lurking, though). This commit doesn't make any serious effort to eliminate transient memory leaks caused by detoasting toasted text objects before they reach text_to_cstring. We changed PG_GETARG_TEXT_P to PG_GETARG_TEXT_PP in a few places where it was easy, but much more could be done. Brendan Jurd and Tom Lane
* Fix a passel of signed vs unsigned char warnings.Tom Lane2007-07-151-9/+9
|
* Replace direct assignments to VARATT_SIZEP(x) with SET_VARSIZE(x, len).Tom Lane2007-02-271-2/+2
| | | | | | | | | | | Get rid of VARATT_SIZE and VARATT_DATA, which were simply redundant with VARSIZE and VARDATA, and as a consequence almost no code was using the longer names. Rename the length fields of struct varlena and various derived structures to catch anyplace that was accessing them directly; and clean up various places so caught. In itself this patch doesn't change any behavior at all, but it is necessary infrastructure if we hope to play any games with the representation of varlena headers. Greg Stark and Tom Lane
* pgindent run for 8.2.Bruce Momjian2006-10-041-1/+1
|
* Rename xml_valid() to xml_is_well_formed(), but provide a temporaryTom Lane2006-09-161-4/+4
| | | | | | alias with the old name for backwards compatibility. Per discussion, the old name is actively wrong because validity and well-formedness have different meanings in XML.
* Move xml2's PG_MODULE_MAGIC block to the right source file, per Michael Fuhr.Tom Lane2006-09-111-0/+3
|
* Remove CXT_printf/CXT1_printf macros. If anyone had found them to be ofTom Lane2006-05-231-3/+3
| | | | | | | | | any use in the past many years, we'd have made some effort to include them in all executor node types; but in fact they were only in nodeAppend.c and nodeIndexscan.c, up until I copied nodeIndexscan.c's occurrence into the new bitmap node types. Remove some other unused macros in execdebug.h, too. Some day the whole header probably ought to go away in favor of better-designed facilities.
* Attached is a patch that replaces a bunch of places where StringInfosNeil Conway2006-03-011-6/+5
| | | | | | | | | | | | | are unnecessarily allocated on the heap rather than the stack. If the StringInfo doesn't outlive the stack frame in which it is created, there is no need to allocate it on the heap via makeStringInfo() -- stack allocation is faster. While it's not a big deal unless the code is in a critical path, I don't see a reason not to save a few cycles -- using stack allocation is not less readable. I also cleaned up a bit of code along the way: moved variable declarations into a more tightly-enclosing scope where possible, fixed some pointless copying of strings in dblink, etc.
* This patch makes the error message strings throughout the backendNeil Conway2006-03-011-4/+4
| | | | | | | | more compliant with the error message style guide. In particular, errdetail should begin with a capital letter and end with a period, whereas errmsg should not. I also fixed a few related issues in passing, such as fixing the repeated misspelling of "lexeme" in contrib/tsearch2 (per Tom's suggestion).
* Standard pgindent run for 8.1.Bruce Momjian2005-10-151-31/+33
|
* Fix inadequate error checking: you can't assume that fcinfo->resultinfoTom Lane2005-07-091-22/+24
| | | | is a ReturnSetInfo unless you've tested it with IsA.
* Fix segfault when xpath_list function is applied to an invalid document.Tom Lane2005-01-091-0/+3
| | | | John Gray
* Attached is a patch that adds the function xml_encode_special_chars toBruce Momjian2004-12-021-0/+29
| | | | | | | the xml2 contrib module. It's against 8.0beta4. It's intended for commit. Markus Bertheau <twanger@bluetwanger.de>