14 Commits (d320101b5b1cde0d0d6d4133f618dd374fc14bea)

Author	SHA1	Message	Date
Tom Lane	d89737d31c	Support "variadic" functions, which can accept a variable number of arguments ... so long as all the trailing arguments are of the same (non-array) type. The function receives them as a single array argument (which is why they have to all be the same type). It might be useful to extend this facility to aggregates, but this patch doesn't do that. This patch imposes a noticeable slowdown on function lookup --- a follow-on patch will fix that by adding a redundant column to pg_proc. Pavel Stehule	17 years ago
Alvaro Herrera	6fff5c3b82	Remove typename from A_Const. ... Brendan Jurd, minor editorialization by me.	18 years ago
Tom Lane	46e9709f48	Remove transformAlterTableStmt's kluge to replace ColumnDef.is_not_null ... flags by separate AT_SetNotNull subcommands. That was always ugly and inefficient, and it's now clear that it was merely a partial workaround for the bug just identified in ATExecAddColumn. This is just code beautification not a bug fix, so no back-patch. Brendan Jurd, with some trivial additional cleanup by me.	18 years ago
Tom Lane	220db7ccd8	Simplify and standardize conversions between TEXT datums and ordinary C ... 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	18 years ago
Tom Lane	20e82a7c0b	Give an explicit error for serial[], rather than silently ignoring ... the array decoration as the code had been doing.	18 years ago
Tom Lane	b7fe5f70d3	Fix CREATE TABLE ... LIKE ... INCLUDING INDEXES to not cause unwanted ... tablespace permissions failures when copying an index that is in the database's default tablespace. A side-effect of the change is that explicitly specifying the default tablespace no longer triggers a permissions check; this is not how it was done in pre-8.3 releases but is argued to be more consistent. Per bug #3921 from Andrew Gilligan. (Note: I argued in the subsequent discussion that maybe LIKE shouldn't copy index tablespaces at all, but since no one indicated agreement with that idea, I've refrained from doing it.)	18 years ago
Bruce Momjian	9098ab9e32	Update copyrights in source tree to 2008.	18 years ago
Tom Lane	265f904d8f	Code review for LIKE ... INCLUDING INDEXES patch. Fix failure to propagate ... constraint status of copied indexes (bug #3774), as well as various other small bugs such as failure to pstrdup when needed. Allow INCLUDING INDEXES indexes to be merged with identical declared indexes (perhaps not real useful, but the code is there and having it not apply to LIKE indexes seems pretty unorthogonal). Avoid useless work in generateClonedIndexStmt(). Undo some poorly chosen API changes, and put a couple of routines in modules that seem to be better places for them.	18 years ago
Bruce Momjian	fdf5a5efb7	pgindent run for 8.3.	18 years ago
Tom Lane	0bd4da23a4	Ensure that typmod decoration on a datatype name is validated in all cases, ... even in code paths where we don't pay any subsequent attention to the typmod value. This seems needed in view of the fact that 8.3's generalized typmod support will accept a lot of bogus syntax, such as "timestamp(foo)" or "record(int, 42)" --- if we allow such things to pass without comment, users will get confused. Per a recent example from Greg Stark. To implement this in a way that's not very vulnerable to future bugs-of-omission, refactor the API of parse_type.c's TypeName lookup routines so that typmod validation is folded into the base lookup operation. Callers can still choose not to receive the encoded typmod, but we'll check the decoration anyway if it's present.	18 years ago
Tom Lane	b17b7fae8c	Remove the hack in the grammar that "optimized away" DEFAULT NULL clauses. ... Instead put in a test to drop a NULL default at the last moment before storing the catalog entry. This changes the behavior in a couple of ways: * Specifying DEFAULT NULL when creating an inheritance child table will successfully suppress inheritance of any default expression from the parent's column, where formerly it failed to do so. * Specifying DEFAULT NULL for a column of a domain type will correctly override any default belonging to the domain; likewise for a sub-domain. The latter change happens because by the time the clause is checked, it won't be a simple null Const but a CoerceToDomain expression. Personally I think this should be back-patched, but there doesn't seem to be consensus for that on pgsql-hackers, so refraining.	18 years ago
Tom Lane	862861ee77	Fix a couple of misbehaviors rooted in the fact that the default creation ... namespace isn't necessarily first in the search path (there could be implicit schemas ahead of it). Examples are test=# set search_path TO s1; test=# create view pg_timezone_names as select * from pg_timezone_names(); ERROR: "pg_timezone_names" is already a view test=# create table pg_class (f1 int primary key); ERROR: permission denied: "pg_class" is a system catalog You'd expect these commands to create the requested objects in s1, since names beginning with pg_ aren't supposed to be reserved anymore. What is happening is that we create the requested base table and then execute additional commands (here, CREATE RULE or CREATE INDEX), and that code is passed the same RangeVar that was in the original command. Since that RangeVar has schemaname = NULL, the secondary commands think they should do a path search, and that means they find system catalogs that are implicitly in front of s1 in the search path. This is perilously close to being a security hole: if the secondary command failed to apply a permission check then it'd be possible for unprivileged users to make schema modifications to system catalogs. But as far as I can find, there is no code path in which a check doesn't occur. Which makes it just a weird corner-case bug for people who are silly enough to want to name their tables the same as a system catalog. The relevant code has changed quite a bit since 8.2, which means this patch wouldn't work as-is in the back branches. Since it's a corner case no one has reported from the field, I'm not going to bother trying to back-patch.	18 years ago
Neil Conway	474774918b	Implement CREATE TABLE LIKE ... INCLUDING INDEXES. Patch from NikhilS, ... based in part on an earlier patch from Trevor Hardcastle, and reviewed by myself.	18 years ago
Tom Lane	46379d6e60	Separate parse-analysis for utility commands out of parser/analyze.c ... (which now deals only in optimizable statements), and put that code into a new file parser/parse_utilcmd.c. This helps clarify and enforce the design rule that utility statements shouldn't be processed during the regular parse analysis phase; all interpretation of their meaning should happen after they are given to ProcessUtility to execute. (We need this because we don't retain any locks for a utility statement that's in a plan cache, nor have any way to detect that it's stale.) We are also able to simplify the API for parse_analyze() and related routines, because they will now always return exactly one Query structure. In passing, fix bug #3403 concerning trying to add a serial column to an existing temp table (this is largely Heikki's work, but we needed all that restructuring to make it safe).	19 years ago