summaryrefslogtreecommitdiff
path: root/src/backend/access/common/indextuple.c
Commit message (Collapse)AuthorAgeFilesLines
* Change tupledesc->attrs[n] to TupleDescAttr(tupledesc, n).Andres Freund2017-08-201-27/+31
| | | | | | | | | | | This is a mechanical change in preparation for a later commit that will change the layout of TupleDesc. Introducing a macro to abstract the details of where attributes are stored will allow us to change that in separate step and revise it in future. Author: Thomas Munro, editorialized by Andres Freund Reviewed-By: Andres Freund Discussion: https://postgr.es/m/CAEepm=0ZtQ-SpsgCyzzYpsXS6e=kZWqk3g5Ygn3MDV7A8dabUA@mail.gmail.com
* Phase 3 of pgindent updates.Tom Lane2017-06-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Update copyright via script for 2017Bruce Momjian2017-01-031-1/+1
|
* Revert CREATE INDEX ... INCLUDING ...Teodor Sigaev2016-04-081-31/+0
| | | | | | It's not ready yet, revert two commits 690c543550b0d2852060c18d270cdb534d339d9a - unstable test output 386e3d7609c49505e079c40c65919d99feb82505 - patch itself
* CREATE INDEX ... INCLUDING (column[, ...])Teodor Sigaev2016-04-081-0/+31
| | | | | | | | | | Now indexes (but only B-tree for now) can contain "extra" column(s) which doesn't participate in index structure, they are just stored in leaf tuples. It allows to use index only scan by using single index instead of two or more indexes. Author: Anastasia Lubennikova with minor editorializing by me Reviewers: David Rowley, Peter Geoghegan, Jeff Janes
* Update copyright for 2016Bruce Momjian2016-01-021-1/+1
| | | | Backpatch certain files through 9.1
* Update copyright for 2015Bruce Momjian2015-01-061-1/+1
| | | | Backpatch certain files through 9.0
* Avoid copying index tuples when building an index.Robert Haas2014-07-011-0/+3
| | | | | | | | | | | | The previous code, perhaps out of concern for avoid memory leaks, formed the tuple in one memory context and then copied it to another memory context. However, this doesn't appear to be necessary, since index_form_tuple and the functions it calls take precautions against leaking memory. In my testing, building the tuple directly inside the sort context shaves several percent off the index build time. Rearrange things so we do that. Patch by me. Review by Amit Kapila, Tom Lane, Andres Freund.
* pgindent run for 9.4Bruce Momjian2014-05-061-3/+3
| | | | | This includes removing tabs after periods in C comments, which was applied to back branches, so this change should not effect backpatching.
* Fix failure to detoast fields in composite elements of structured types.Tom Lane2014-05-011-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we have an array of records stored on disk, the individual record fields cannot contain out-of-line TOAST pointers: the tuptoaster.c mechanisms are only prepared to deal with TOAST pointers appearing in top-level fields of a stored row. The same applies for ranges over composite types, nested composites, etc. However, the existing code only took care of expanding sub-field TOAST pointers for the case of nested composites, not for other structured types containing composites. For example, given a command such as UPDATE tab SET arraycol = ARRAY[(ROW(x,42)::mycompositetype] ... where x is a direct reference to a field of an on-disk tuple, if that field is long enough to be toasted out-of-line then the TOAST pointer would be inserted as-is into the array column. If the source record for x is later deleted, the array field value would become a dangling pointer, leading to errors along the line of "missing chunk number 0 for toast value ..." when the value is referenced. A reproducible test case for this was provided by Jan Pecek, but it seems likely that some of the "missing chunk number" reports we've heard in the past were caused by similar issues. Code-wise, the problem is that PG_DETOAST_DATUM() is not adequate to produce a self-contained Datum value if the Datum is of composite type. Seen in this light, the problem is not just confined to arrays and ranges, but could also affect some other places where detoasting is done in that way, for example form_index_tuple(). I tried teaching the array code to apply toast_flatten_tuple_attribute() along with PG_DETOAST_DATUM() when the array element type is composite, but this was messy and imposed extra cache lookup costs whether or not any TOAST pointers were present, indeed sometimes when the array element type isn't even composite (since sometimes it takes a typcache lookup to find that out). The idea of extending that approach to all the places that currently use PG_DETOAST_DATUM() wasn't attractive at all. This patch instead solves the problem by decreeing that composite Datum values must not contain any out-of-line TOAST pointers in the first place; that is, we expand out-of-line fields at the point of constructing a composite Datum, not at the point where we're about to insert it into a larger tuple. This rule is applied only to true composite Datums, not to tuples that are being passed around the system as tuples, so it's not as invasive as it might sound at first. With this approach, the amount of code that has to be touched for a full solution is greatly reduced, and added cache lookup costs are avoided except when there actually is a TOAST pointer that needs to be inlined. The main drawback of this approach is that we might sometimes dereference a TOAST pointer that will never actually be used by the query, imposing a rather large cost that wasn't there before. On the other side of the coin, if the field value is used multiple times then we'll come out ahead by avoiding repeat detoastings. Experimentation suggests that common SQL coding patterns are unaffected either way, though. Applications that are very negatively affected could be advised to modify their code to not fetch columns they won't be using. In future, we might consider reverting this solution in favor of detoasting only at the point where data is about to be stored to disk, using some method that can drill down into multiple levels of nested structured types. That will require defining new APIs for structured types, though, so it doesn't seem feasible as a back-patchable fix. Note that this patch changes HeapTupleGetDatum() from a macro to a function call; this means that any third-party code using that macro will not get protection against creating TOAST-pointer-containing Datums until it's recompiled. The same applies to any uses of PG_RETURN_HEAPTUPLEHEADER(). It seems likely that this is not a big problem in practice: most of the tuple-returning functions in core and contrib produce outputs that could not possibly be toasted anyway, and the same probably holds for third-party extensions. This bug has existed since TOAST was invented, so back-patch to all supported branches.
* Allow use of "z" flag in our printf calls, and use it where appropriate.Tom Lane2014-01-231-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Since C99, it's been standard for printf and friends to accept a "z" size modifier, meaning "whatever size size_t has". Up to now we've generally dealt with printing size_t values by explicitly casting them to unsigned long and using the "l" modifier; but this is really the wrong thing on platforms where pointers are wider than longs (such as Win64). So let's start using "z" instead. To ensure we can do that on all platforms, teach src/port/snprintf.c to understand "z", and add a configure test to force use of that implementation when the platform's version doesn't handle "z". Having done that, modify a bunch of places that were using the unsigned-long hack to use "z" instead. This patch doesn't pretend to have gotten everyplace that could benefit, but it catches many of them. I made an effort in particular to ensure that all uses of the same error message text were updated together, so as not to increase the number of translatable strings. It's possible that this change will result in format-string warnings from pre-C99 compilers. We might have to reconsider if there are any popular compilers that will warn about this; but let's start by seeing what the buildfarm thinks. Andres Freund, with a little additional work by me
* Update copyright for 2014Bruce Momjian2014-01-071-1/+1
| | | | | Update all files in head, and files COPYRIGHT and legal.sgml in all back branches.
* Update copyrights for 2013Bruce Momjian2013-01-011-1/+1
| | | | | Fully update git head, and update back branches in ./COPYRIGHT and legal.sgml files.
* Update copyright notices for year 2012.Bruce Momjian2012-01-011-1/+1
|
* pgindent run before PG 9.1 beta 1.Bruce Momjian2011-04-101-1/+1
|
* Stamp copyrights for year 2011.Bruce Momjian2011-01-011-1/+1
|
* Remove cvs keywords from all files.Magnus Hagander2010-09-201-1/+1
|
* Remove partial, broken support for NULL pointers when fetching attributes.Robert Haas2010-01-101-36/+3
| | | | | | | | | | | | | | Previously, fastgetattr() and heap_getattr() tested their fourth argument against a null pointer, but any attempt to use them with a literal-NULL fourth argument evaluated to *(void *)0, resulting in a compiler error. Remove these NULL tests to avoid leading future readers of this code to believe that this has a chance of working. Also clean up related legacy code in nocachegetattr(), heap_getsysattr(), and nocache_index_getattr(). The new coding standard is that any code which calls a getattr-type function or macro which takes an isnull argument MUST pass a valid boolean pointer. Per discussion with Bruce Momjian, Tom Lane, Alvaro Herrera.
* Update copyright for the year 2010.Bruce Momjian2010-01-021-2/+2
|
* Improve unique-constraint-violation error messages to include the exactTom Lane2009-08-011-1/+22
| | | | | | | | | values being complained of. In passing, also remove the arbitrary length limitation in the similar error detail message for foreign key violations. Itagaki Takahiro
* 8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef listBruce Momjian2009-06-111-3/+3
| | | | provided by Andrew.
* Update copyright for 2009.Bruce Momjian2009-01-011-2/+2
|
* Clean up a few places where Datums were being treated as pointers (and viceAlvaro Herrera2008-04-171-4/+4
| | | | | | versa) without going through DatumGetPointer. Gavin Sherry, with Feng Tian.
* Update copyrights in source tree to 2008.Bruce Momjian2008-01-011-2/+2
|
* pgindent run for 8.3.Bruce Momjian2007-11-151-12/+12
|
* Use "alternative" instead of "alternate" where it is clearer.Peter Eisentraut2007-11-071-2/+2
|
* Support varlena fields with single-byte headers and unaligned storage.Tom Lane2007-04-061-53/+89
| | | | | | | | | This commit breaks any code that assumes that the mere act of forming a tuple (without writing it to disk) does not "toast" any fields. While all available regression tests pass, I'm not totally sure that we've fixed every nook and cranny, especially in contrib. Greg Stark with some help from Tom Lane
* 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
* Update CVS HEAD for 2007 copyright. Back branches are typically notBruce Momjian2007-01-051-2/+2
| | | | back-stamped for this.
* Fix misguided removal of access/tuptoaster.h inclusion, per Kris Jurka.Tom Lane2006-07-141-1/+2
| | | | | | I'm going to insist on reversion of this entire patch unless pgrminclude is upgraded to a less broken state, but in the meantime let's get contrib passing regression again.
* Remove 576 references of include files that were not needed.Bruce Momjian2006-07-141-3/+1
|
* Alphabetically order reference to include files, "G" - "M".Bruce Momjian2006-07-111-2/+2
|
* Update copyright for 2006. Update scripts.Bruce Momjian2006-03-051-2/+2
|
* Standard pgindent run for 8.1.Bruce Momjian2005-10-151-19/+18
|
* Eliminate duplicate hasnulls bit testing in index tuple access, andTom Lane2005-03-271-5/+4
| | | | clean up itup.h a little bit.
* Convert index-related tuple handling routines from char 'n'/' ' to boolTom Lane2005-03-211-32/+33
| | | | | | | | | | convention for isnull flags. Also, remove the useless InsertIndexResult return struct from index AM aminsert calls --- there is no reason for the caller to know where in the index the tuple was inserted, and we were wasting a palloc cycle per insert to deliver this uninteresting value (plus nontrivial complexity in some AMs). I forced initdb because of the change in the signature of the aminsert routines, even though nothing really looks at those pg_proc entries...
* Tag appropriate files for rc3PostgreSQL Daemon2004-12-311-2/+2
| | | | | | | | Also performed an initial run through of upgrading our Copyright date to extend to 2005 ... first run here was very simple ... change everything where: grep 1996-2004 && the word 'Copyright' ... scanned through the generated list with 'less' first, and after, to make sure that I only picked up the right entries ...
* Pgindent run for 8.0.Bruce Momjian2004-08-291-4/+4
|
* Update copyright to 2004.Bruce Momjian2004-08-291-2/+2
|
* $Header: -> $PostgreSQL Changes ...PostgreSQL Daemon2003-11-291-1/+1
|
* Message editing: remove gratuitous variations in message wording, standardizePeter Eisentraut2003-09-251-3/+3
| | | | | terms, add some clarifications, fix some untranslatable attempts at dynamic message building.
* Update copyrights to 2003.Bruce Momjian2003-08-041-2/+2
|
* pgindent run.Bruce Momjian2003-08-041-4/+4
|
* Error message editing in backend/access.Tom Lane2003-07-211-5/+10
|
* First cut at recycling space in btree indexes. Still some rough edgesTom Lane2003-02-231-9/+8
| | | | to fix, but it seems to basically work...
* Add new palloc0 call as merge of palloc and MemSet(0).Bruce Momjian2002-11-131-3/+2
|
* Back out use of palloc0 in place if palloc/MemSet. Seems constant lenBruce Momjian2002-11-111-2/+3
| | | | to MemSet is a performance boost.
* Merge palloc()/MemSet(0) calls into a single palloc0() call.Bruce Momjian2002-11-101-3/+2
|
* pgindent run.Bruce Momjian2002-09-041-4/+4
|
* Clean up comments to be careful about the distinction between variable-Tom Lane2002-08-251-7/+7
| | | | | | | | | | width types and varlena types, since with the introduction of CSTRING as a more-or-less-real type, these concepts aren't identical. I've tried to use varlena consistently to denote datatypes with typlen = -1, ie, they have a length word and are potentially TOASTable; while the term variable width covers both varlena and cstring (and, perhaps, someday other types with other rules for computing the actual width). No code changes in this commit except for renaming a couple macros.