| Age | Commit message (Collapse) | Author |
|---|
|
Example:
test=# \d test
Table "public.test"
Column | Type | Modifiers
--------+---------+-----------
a | integer | not null
Indexes:
"test_pkey" PRIMARY KEY btree (a)
Check Constraints:
"$2" CHECK (a > 1)
Foreign Key Constraints:
"$1" FOREIGN KEY (a) REFERENCES parent(b)
Rules:
myrule AS ON INSERT TO test DO INSTEAD NOTHING
Triggers:
"asdf asdf" AFTER INSERT OR DELETE ON test FOR EACH STATEMENT EXECUTE
PROCEDURE update_pg_pwd_and_pg_group(),
mytrigger AFTER INSERT OR DELETE ON test FOR EACH ROW EXECUTE PROCEDURE
update_pg_pwd_and_pg_group()
I have minimised the double quoting of identifiers as much as I could
easily, and I will submit another patch when I have time to work on it that
will use a 'fmtId' function to determine it exactly.
I think it's a significant improvement in legibility...
Obviously the table example above is slightly degenerate in that not many
tables in production have heaps of (non-constraint) triggers and rules.
Christopher Kings-Lynne
|
|
|
|
|
|
(materialization into a tuple store) discussed on pgsql-hackers earlier.
I've updated the documentation and the regression tests.
Notes on the implementation:
- I needed to change the tuple store API slightly -- it assumes that it
won't be used to hold data across transaction boundaries, so the temp
files that it uses for on-disk storage are automatically reclaimed at
end-of-transaction. I added a flag to tuplestore_begin_heap() to control
this behavior. Is changing the tuple store API in this fashion OK?
- in order to store executor results in a tuple store, I added a new
CommandDest. This works well for the most part, with one exception: the
current DestFunction API doesn't provide enough information to allow the
Executor to store results into an arbitrary tuple store (where the
particular tuple store to use is chosen by the call site of
ExecutorRun). To workaround this, I've temporarily hacked up a solution
that works, but is not ideal: since the receiveTuple DestFunction is
passed the portal name, we can use that to lookup the Portal data
structure for the cursor and then use that to get at the tuple store the
Portal is using. This unnecessarily ties the Portal code with the
tupleReceiver code, but it works...
The proper fix for this is probably to change the DestFunction API --
Tom suggested passing the full QueryDesc to the receiveTuple function.
In that case, callers of ExecutorRun could "subclass" QueryDesc to add
any additional fields that their particular CommandDest needed to get
access to. This approach would work, but I'd like to think about it for
a little bit longer before deciding which route to go. In the mean time,
the code works fine, so I don't think a fix is urgent.
- (semi-related) I added a NO SCROLL keyword to DECLARE CURSOR, and
adjusted the behavior of SCROLL in accordance with the discussion on
-hackers.
- (unrelated) Cleaned up some SGML markup in sql.sgml, copy.sgml
Neil Conway
|
|
The first cleans up a couple of minor errors and ommissions
and adds tab completion support to more slash commands, e.g.
\dv.
The second is an attempt to add tab completion for schemas
and fully qualified relation names (e.g. public.mytable ).
I think this covers the TODO-item:
"Allow psql to do table completion for SELECT * FROM schema_part and table
completion for SELECT * FROM schema_name."
This happens via union selects querying:
- relation_name in current search path;
- schema_name;
- schema.relation_name
matching the current input string.
E.g:
SELECT p[TAB]
will produce a list of all appropriate relation names in the current search
path which begin with 'p', and also all schema names which begin with 'p';
\d pub[TAB]
will produce any relation names in the current search path and also
any schema names beginning with 'pub';
\d public.[TAB]
will produce a list of all relations in the schema 'public';
\d public.my[TAB]
produces all relation names beginning with 'my' in schema 'public'.
It seems to work for me; comments, suggestions, particularly regarding
the coding and queries, are very welcome.
Note that tables, indexes, views and sequences relations in the
'pg_catalog' namespace are excluded even though they are in
the current search path. I found not doing this produced annoying behaviour
when expanding names beginning with 'p'. People who work with system
tables a lot may not like this though; I can look for another solution
if necessary.
Ian Barwick
|
|
ALTER TABLE foo CLUSTER ON bar;
In pg_dumps, to preserve cluster settings.
Christopher Kings-Lynne
|
|
Laurent FAILLIE
|
|
|
|
qual checking, not GetCurrentCommandId. Per test case from Steve Wolfe.
|
|
|
|
vague cross-references with real links.
|
|
x[42] := whatever;
The facility is pretty primitive because it doesn't do array slicing and
it has the same semantics as array update in SQL (array must already
be non-null, etc). But it's a start.
|
|
|
|
Keep PQfreeNotify() around for binary compatibility.
|
|
two columns in a table are both foreign keys to another table. From Peter Royal proyal@pace2020.com
|
|
subsequent updates patch from Shawn Green, slightly modified
|
|
This is to help localize the changes needed for adding a new kind of
PLpgSQL_datum (like, say, an array element...)
|
|
disk-full conditions instead of provoking a backend crash. Per suggestion
from Frederic Surleau.
|
|
returns NULL. This avoids out-of-buffers failures during many-way
indexscans, as in Shraibman's complaint of 21-Mar.
|
|
#search_path = '$user,public' # schema names
|
|
when autocommit is off, and document grouping when autocommit is on.
|
|
|
|
full privs), also updated the regression test for this case.
Modified Files:
jdbc/org/postgresql/jdbc1/AbstractJdbc1DatabaseMetaData.java
jdbc/org/postgresql/test/jdbc2/DatabaseMetaDataTest.java
|
|
NULL key pointer, indicating that the existing scan key should be reused.
This behavior isn't used yet but will be needed for my planned fix to
the keys_are_unique code.
|
|
them as arrays of the internal datatype. This requires treating the
stavalues columns as 'anyarray' rather than 'text[]', which is not 100%
kosher but seems to work fine for the purposes we need for pg_statistic.
Perhaps in the future 'anyarray' will be allowed more generally.
|
|
from Andreas Pflug.
|
|
|
|
|
|
appropriate targetlist entry out of the subquery. Use an explicit search
like we do everywhere else.
|
|
Cleans up blank query handling to be more consistent.
|
|
|
|
|
|
refers to a non-DISTINCT output column of a DISTINCT ON subquery, or
if it refers to a function-returning-set, we cannot push it down.
But the old implementation refused to push down *any* quals if the
subquery had any such 'dangerous' outputs. Now we just look at the
output columns actually referenced by each qual expression. More code
than before, but probably no slower since we don't make unnecessary checks.
|
|
|
|
+ <entry><function>hostmask</function>(<type>inet</type>)</entry>
+ <entry><type>inet</type></entry>
+ <entry>construct hostmask for network</entry>
+ <entry><literal>hostmask('192.168.23.20/30')</literal></entry>
+ <entry><literal>0.0.0.3</literal></entry>
Greg Wickham
|
|
configure under native Windows (MinGW that is), but you won't get very far
compiling yet. The dynaloader files are from Jan Wieck's patch set.
|
|
Alvaro Herrera1
|
|
|
|
|
|
|
|
|
|
|
|
some of the algorithms for higher functions. I see about a factor of ten
speedup on the 'numeric' regression test, but it's unlikely that that test
is representative of real-world applications.
initdb forced due to change of on-disk representation for NUMERIC.
|
|
|
|
|
|
a trigger as its parameter. It is basically copied from the pg_dump
code.
Christopher Kings-Lynne
|
|
be simplified (I'd thought that it can even be removed). This patch
does that.
Alvaro Herrera
|
|
Alvaro Herrera
|
|
queries while the rest remain blank.
Kevin Brown
|
|
|
