Re: [PATCHES] [HACKERS] For review: Server instrumentation patch
Bruce Momjian wrote: True, but that is more for the application. I don't imagine a user looking at that from psql would have a problem. However, you asked for a query that looks like pg_ls_logdir() and here it is: SELECT pg_ls_dir FROM( SELECT pg_ls_dir(t1.setting) FROM(SELECT setting FROM pg_settings WHERE NAME = 'log_directory') AS t1 ) AS t2, (SELECT setting FROM pg_settings WHERE NAME = 'log_filename') AS t3 WHERE t2.pg_ls_dir LIKE regexp_replace(t3.setting, '%.*', '') || '%'; The one thing it doesn't do, as you mentioned, is check for valid dates, but it is certainly more flexible than embedding something in the backend. The interesting part of pg_logdir_ls is the filetime, to enable SELECT pg_file_unlink(filename) FROM pg_logdir_ls() WHERE filetime now() - '30 days'::interval Regards, Andreas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [patch 0/7] more patches for pgcrypto
On Fri, Aug 12, 2005 at 10:06:21PM -0400, Bruce Momjian wrote: Thanks. All seven applied. Good, but you missed one step: 'cvs remove API' -- marko ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[PATCHES] psql tab-complete and backslash patch
Hi!
attached is a patch against psql that makes psql's tabcomplete code
ROLES aware, adds SET SCHEMA and basic CREATE DATABASE/TRIGGER support
as well as some other minor things.
In addition to this I modified \du to display a list of roles with some
additional information(createrole,connection limit) on 8.1 with a
fallback to the original output on older backends.
There are a few problems still left - in particular the the tab-complete
code is a little inconsistent wrt completing USER/ROLE/GROUP/OWNER TO
with roles or users/groups (from the pg_user/pg_group views)
comments(especially about the \du change)?
regards
Stefan Kaltenbrunner
Changes in Detail:
*) SET SCHEMA for ALTER AGGREGATE,FUNCTION.DOMAIN,SEQUENCE,TABLE,TYPE
*) add CONNECTION LIMIT to ALTER DATABASE
*) add support for ALTER ROLE
*) make ALTER USER aware about ROLES
*) COMMENT ON LARGE OBJECT
*) add support for CREATE DATABASE
*) add support for CREATE TRIGGER
*) add support for CREATE USER,ROLE,GROUP
*) complete SET ROLE with a list of roles
*) complete SET SCHEMA with a list of schemas
*) complete SET SESSION AUTHORIZATION with list of roles
*) fixes a small typo in a comment (ANALZYE - ANALYZE)
*) modify \du to display createrole and the connection limit
Index: src/bin/psql/command.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/psql/command.c,v
retrieving revision 1.151
diff -u -r1.151 command.c
--- src/bin/psql/command.c 25 Jul 2005 17:17:41 - 1.151
+++ src/bin/psql/command.c 13 Aug 2005 10:47:36 -
@@ -363,7 +363,7 @@
success = listTables(cmd[1], pattern,
show_verbose);
break;
case 'u':
- success = describeUsers(pattern);
+ success = describeRoles(pattern);
break;
default:
Index: src/bin/psql/describe.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/psql/describe.c,v
retrieving revision 1.122
diff -u -r1.122 describe.c
--- src/bin/psql/describe.c 18 Jul 2005 19:09:09 - 1.122
+++ src/bin/psql/describe.c 13 Aug 2005 10:47:38 -
@@ -1379,23 +1379,24 @@
/*
* \du
*
- * Describes users. Any schema portion of the pattern is ignored.
+ * Describes Roles. Any schema portion of the pattern is ignored.
*/
bool
-describeUsers(const char *pattern)
+describeRoles(const char *pattern)
{
PQExpBufferData buf;
PGresult *res;
printQueryOpt myopt = pset.popt;
initPQExpBuffer(buf);
-
+ if (pset.sversion 80100)
+{
printfPQExpBuffer(buf,
SELECT u.usename AS \%s\,\n
u.usesysid AS \%s\,\n
CASE WHEN u.usesuper AND
u.usecreatedb THEN CAST('%s' AS pg_catalog.text)\n
- WHEN u.usesuper THEN CAST('%s' AS
pg_catalog.text)\n
- WHEN u.usecreatedb THEN CAST('%s' AS
pg_catalog.text)\n
+WHEN u.usesuper THEN
CAST('%s' AS pg_catalog.text)\n
+WHEN u.usecreatedb THEN
CAST('%s' AS pg_catalog.text)\n
ELSE CAST('' AS
pg_catalog.text)\n
END AS \%s\,\n
ARRAY(SELECT g.groname FROM
pg_catalog.pg_group g WHERE u.usesysid = ANY(g.grolist)) as \%s\\n
@@ -1408,6 +1409,37 @@
processNamePattern(buf, pattern, false, false,
NULL, u.usename, NULL, NULL);
+ myopt.title = _(List of users);
+} else {
+ printfPQExpBuffer(buf,
+ SELECT r.rolname AS \%s\,\n
+ CASE WHEN r.rolsuper AND
r.rolcreaterole AND r.rolcreatedb THEN CAST('%s' AS pg_catalog.text)\n
+ WHEN r.rolsuper AND
r.rolcreaterole THEN CAST('%s' AS pg_catalog.text)\n
+ WHEN r.rolsuper AND r.rolcreatedb
THEN CAST('%s' AS pg_catalog.text)\n
+ WHEN r.rolsuper THEN CAST('%s' AS
pg_catalog.text)\n
+ WHEN r.rolcreaterole AND
r.rolcreatedb THEN CAST('%s' AS pg_catalog.text)\n
+ WHEN r.rolcreaterole THEN
CAST('%s' AS pg_catalog.text)\n
+ WHEN r.rolcreatedb THEN CAST('%s'
AS pg_catalog.text)\n
+ ELSE CAST('' AS pg_catalog.text)\n
+ END AS \%s\,\n
+ CASE WHEN
Re: [PATCHES] [BUGS] BUG #1815: ECPGdebug causes crash on Windows XP
Bruce Momjian pgman@candle.pha.pa.us wrote:[EMAIL PROTECTED] William ZHANG wrote: Make sure the lib directory is in the PATH. I tested it in MinGW. $ ecpg main.pgc $ gcc main.c -I../include -L../lib -lecpg $ export PATH=$PATH:/c/Program Files/PostgreSQL/8.0/lib $ ./a.exe [1772]: ECPGdebug: set to 1 Ah, interesting. Why would it crash if the lib directory is not in the path? Because it can't load the library? Maybe I misunderstood the word 'crash'. If I forgot to put the lib directory, it will make Windows popup a GUI warning window. joshua masiko: Can you give more information? ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] For review: Server instrumentation patch
Andreas Pflug [EMAIL PROTECTED] writes: Bruce Momjian wrote: Well, if they mix log files and non-log files in the same directory, we would have to filter based on the log_filename directive in the application, or use LIKE in a query. .. which is what pg_logdir_ls does. And it's robust against filenames that don't have valid dates too; imagine postgresql-2005-01-01_crash1.log. The proposed version of pg_logdir_ls could not be called robust in any way at all, considering that it fails as soon as you modify the log_filename pattern. I concur with Bruce that this is better left to the application side. I don't see any basic functionality gain from doing it in the server. The client code can look at log_filename and do the filtering just as well (or badly) as it could possibly be done in the server. Moreover, having a restriction like this doesn't work unless you use this log_filename setting feels more reasonable on the client side than inside the server. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [HACKERS] For review: Server instrumentation patch
Bruce Momjian pgman@candle.pha.pa.us writes: What I can imagine making things very easy is a readonly GUC that returns the current log file name. ... which unfortunately is not going to happen since the backends can't see inside the syslogger process to know what it's doing. ATM I think the best you can do is look for the newest mod date among the files in the log directory. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] ECPG ignores SAVEPOINT if first statement of a transaction
On Fri, Aug 12, 2005 at 10:22:32PM -0400, Bruce Momjian wrote:
Michael Fuhr wrote:
ECPG ignores SAVEPOINT if it's the first statement of a transaction:
ECPGtrans() ignores the statement because of this check:
/*
* if we are not in autocommit mode, already have committed the
* transaction and get another commit, just ignore it
*/
if (!con-committed || con-autocommit)
{
if ((res = PQexec(con-connection, transaction)) == NULL)
{
ECPGraise(lineno, ECPG_TRANS,
ECPG_SQLSTATE_TRANSACTION_RESOLUTION_UNKNOWN, NULL);
return FALSE;
}
PQclear(res);
}
If no statements have been executed in this transaction then committed
is true, so ECPGtrans() ignores the current statement. It looks
like the code should make an extra consideration for SAVEPOINT in
case it's the first statement.
I'm also wondering if the check for a NULL return value from PQexec()
is sufficient. Shouldn't it also check for a non-NULL result that's
anything other than PGRES_COMMAND_OK?
--
Michael Fuhr
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Re: [PATCHES] [HACKERS] For review: Server instrumentation patch
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
What I can imagine making things very easy is a readonly GUC that returns
the current log file name.
... which unfortunately is not going to happen since the backends can't
see inside the syslogger process to know what it's doing.
That's a shame.
ATM I think the best you can do is look for the newest mod date among
the files in the log directory.
I guess, but then you have the pattern problem, especially if you are
putting things in /var/log where there are other log files too.
One idea would be to implement pg_ls_logdir() as a system view, and then
build a GUC on that, but I am not sure that is possible. Here is an
updated version of the query that also checks the file extension:
SELECT pg_ls_dir
FROM(
SELECT pg_ls_dir(t1.setting)
FROM(SELECT setting FROM pg_settings
WHERE NAME = 'log_directory') AS t1
) AS t2,
(SELECT setting FROM pg_settings
WHERE NAME = 'log_filename') AS t3
WHERE t2.pg_ls_dir LIKE regexp_replace(t3.setting, '%.*', '') ||
'%' || regexp_replace(t3.setting, '.*\\.', '.') ;
pg_ls_dir
--
postgresql-2005-08-12_211251.log
postgresql-2005-08-13_00.log
(2 rows)
Also, do we have a way to return columns from a system-installed
function? I really don't like that pg_stat_file() to returns a record
rather than named columns. How do I even access the individual record
values?
test= select pg_stat_file('.');
pg_stat_file
---
(512,2005-08-12 21:13:01,2005-08-13 07:08:54,2005-08-12
21:13:01,t)
(1 row)
test= select pg_stat_file('.')[1];
ERROR: syntax error at or near [ at character 25
We have system _tables_ that return columns, like pg_settings, but of
course that doesn't take any arguments, just a WHERE clause, so that
wouldn't work here.
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [PATCHES] [patch 0/7] more patches for pgcrypto
Marko Kreen wrote: On Fri, Aug 12, 2005 at 10:06:21PM -0400, Bruce Momjian wrote: Thanks. All seven applied. Good, but you missed one step: 'cvs remove API' Uh, I reread your emails and couldn't find what file to remove. Which ones? -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [patch 0/7] more patches for pgcrypto
On Sat, Aug 13, 2005 at 11:12:18AM -0400, Bruce Momjian wrote: Marko Kreen wrote: On Fri, Aug 12, 2005 at 10:06:21PM -0400, Bruce Momjian wrote: Thanks. All seven applied. Good, but you missed one step: 'cvs remove API' Uh, I reread your emails and couldn't find what file to remove. Which ones? Heh. The file API. See last patch. -- marko ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [patch 0/7] more patches for pgcrypto
Marko Kreen wrote: On Sat, Aug 13, 2005 at 11:12:18AM -0400, Bruce Momjian wrote: Marko Kreen wrote: On Fri, Aug 12, 2005 at 10:06:21PM -0400, Bruce Momjian wrote: Thanks. All seven applied. Good, but you missed one step: 'cvs remove API' Uh, I reread your emails and couldn't find what file to remove. Which ones? Heh. The file API. See last patch. Ah, API is a file name. File removed. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] [HACKERS] For review: Server instrumentation patch
Tom Lane wrote: Andreas Pflug [EMAIL PROTECTED] writes: Bruce Momjian wrote: Well, if they mix log files and non-log files in the same directory, we would have to filter based on the log_filename directive in the application, or use LIKE in a query. .. which is what pg_logdir_ls does. And it's robust against filenames that don't have valid dates too; imagine postgresql-2005-01-01_crash1.log. The proposed version of pg_logdir_ls could not be called robust in any way at all, considering that it fails as soon as you modify the log_filename pattern. This is caused by the exposure of log_filename, I never proposed to do that for good reasons. Any try to interpret it and read files back will break finally when log_filename is changed at runtime, i.e. it's a 'break me' option by design. Regards, Andreas ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] For review: Server instrumentation patch
Bruce Momjian wrote:
Also, do we have a way to return columns from a system-installed
function? I really don't like that pg_stat_file() to returns a record
rather than named columns. How do I even access the individual record
values?
As in pg_settings:
SELECT length, mtime FROM pg_file_stat('postgresql.conf') AS st(length
int4, ctime timestamp, atime timestamp, mtime timestamp, isdir bool)
Regards,
Andreas
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] For review: Server instrumentation patch
Bruce Momjian pgman@candle.pha.pa.us writes:
SELECT pg_ls_dir
FROM(
SELECT pg_ls_dir(t1.setting)
FROM(SELECT setting FROM pg_settings
WHERE NAME = 'log_directory') AS t1
) AS t2,
(SELECT setting FROM pg_settings
WHERE NAME = 'log_filename') AS t3
WHERE t2.pg_ls_dir LIKE regexp_replace(t3.setting, '%.*', '') ||
'%' || regexp_replace(t3.setting, '.*\\.', '.') ;
This is unnecessarily complicated --- use current_setting, eg,
select * from pg_ls_dir(current_setting('log_directory'))
where pg_ls_dir like
regexp_replace(current_setting('log_filename'), '%.', '%', 'g');
I really don't like that pg_stat_file() to returns a record
rather than named columns. How do I even access the individual record
values?
select * from See the documentation:
Use it like this:
SELECT *
FROM pg_stat_file('filename')
AS s(length int8, atime timestamptz, mtime timestamptz,
ctime timestamptz, isdir bool);
I suppose as long it's just this one function at stake, we could imagine
fixing the pg_proc row after-the-fact (later in the initdb sequence).
Pretty klugy but something nicer could get done in the 8.2 time frame.
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] For review: Server instrumentation patch
Andreas Pflug wrote:
Bruce Momjian wrote:
Also, do we have a way to return columns from a system-installed
function? I really don't like that pg_stat_file() to returns a record
rather than named columns. How do I even access the individual record
values?
As in pg_settings:
SELECT length, mtime FROM pg_file_stat('postgresql.conf') AS st(length
int4, ctime timestamp, atime timestamp, mtime timestamp, isdir bool)
Ewe, that is ugly. How does the user even know the data types? int4 or
int8? timestamp or timestamptz? \df doesn't show it:
pg_catalog | pg_stat_file| record | text
and it isn't in the documenation. However, internally, it knows. In
fact your example is wrong because the size it int8, not int4:
test= SELECT length, mtime FROM pg_stat_file('postgresql.conf') AS
st(length
test( int4, ctime timestamp, atime timestamp, mtime timestamp, isdir
bool);
ERROR: function return row and query-specified return row do not match
DETAIL: Returned type bigint at ordinal position 1, but query expects
integer.
test= SELECT length, mtime FROM pg_stat_file('postgresql.conf') AS
st(length
test( int8, ctime timestamp, atime timestamp, mtime timestamp, isdir
bool);
length |mtime
+-
12576 | 2005-08-12 21:12:36
(1 row)
Let me repond to Tom's email.
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [PATCHES] [HACKERS] For review: Server instrumentation patch
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
SELECT pg_ls_dir
FROM(
SELECT pg_ls_dir(t1.setting)
FROM(SELECT setting FROM pg_settings
WHERE NAME = 'log_directory') AS t1
) AS t2,
(SELECT setting FROM pg_settings
WHERE NAME = 'log_filename') AS t3
WHERE t2.pg_ls_dir LIKE regexp_replace(t3.setting, '%.*', '') ||
'%' || regexp_replace(t3.setting, '.*\\.', '.') ;
This is unnecessarily complicated --- use current_setting, eg,
select * from pg_ls_dir(current_setting('log_directory'))
where pg_ls_dir like
regexp_replace(current_setting('log_filename'), '%.', '%', 'g');
Nice.
I really don't like that pg_stat_file() to returns a record
rather than named columns. How do I even access the individual record
values?
select * from See the documentation:
Use it like this:
SELECT *
FROM pg_stat_file('filename')
AS s(length int8, atime timestamptz, mtime timestamptz,
ctime timestamptz, isdir bool);
I suppose as long it's just this one function at stake, we could imagine
fixing the pg_proc row after-the-fact (later in the initdb sequence).
Pretty klugy but something nicer could get done in the 8.2 time frame.
Yes, see my earlier email --- we don't even document the return type of
the function, nor does \df show it. This seems too hard to use.
I am worried that if we improve things in 8.2, we would then be changing
the API of the function. Are the other functions returning records usable?
Could we fix it in a way that later improvements would maintain the same
API?
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] For review: Server instrumentation patch
Bruce Momjian pgman@candle.pha.pa.us writes: Tom Lane wrote: I suppose as long it's just this one function at stake, we could imagine fixing the pg_proc row after-the-fact (later in the initdb sequence). Pretty klugy but something nicer could get done in the 8.2 time frame. Yes, see my earlier email --- we don't even document the return type of the function, nor does \df show it. This seems too hard to use. I am worried that if we improve things in 8.2, we would then be changing the API of the function. Yeah, we would. Are the other functions returning records usable? All the other ones are meant to be used via views, so it doesn't matter so much. pg_stat_file can't very usefully be called through a view, so we have a problem. I'll see about installing an initdb-time kluge to make it use OUT parameters. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] [HACKERS] For review: Server instrumentation patch
I wrote:
I'll see about installing an initdb-time kluge to make it use OUT
parameters.
Done:
regression=# SELECT * FROM pg_stat_file('postgresql.conf');
length | atime | mtime | ctime
| isdir
++++---
12578 | 2005-08-13 14:51:03-04 | 2005-08-13 14:50:32-04 | 2005-08-13
14:50:32-04 | f
(1 row)
I removed the separate pg_file_length() function, as it doesn't have any
significant notational advantage anymore; you can do
regression=# select (pg_stat_file('postgresql.conf')).length;
length
12578
(1 row)
BTW, \df is no real help when it comes to stuff with OUT parameters;
it still says
regression=# \df pg_stat_file
List of functions
Schema | Name | Result data type | Argument data types
+--+--+-
pg_catalog | pg_stat_file | record | text
(1 row)
Possibly we should try to improve that.
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
[PATCHES] [PATCH] Clarify issues with SPI and C language function limitations
[Please CC any replies] Hi, Here is a patch to the documentation clarifying some minor issues. The first is to the main SPI documentation clarifying that SPI isn't available unless there is a current snapshot (leading to the no snapshot has been set error). The second clarifies when the get_fn_expr_rettype() and get_fn_expr_argtype() functions can actually provide the information requested. Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a tool for doing 5% of the work and then sitting around waiting for someone else to do the other 95% so you can sue them. Index: doc/src/sgml/spi.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/spi.sgml,v retrieving revision 1.42 diff -u -r1.42 spi.sgml --- doc/src/sgml/spi.sgml 29 Jul 2005 13:00:03 - 1.42 +++ doc/src/sgml/spi.sgml 13 Aug 2005 19:10:54 - @@ -29,6 +29,14 @@ /para /note + note + para + SPI can not be used in functions called prior to the start of query + execution because there is no current snapshot at that point. Examples of + this include type input functions and cost estimation functions. + /para + /note + para To avoid misunderstanding we'll use the term quotefunction/quote when we speak of acronymSPI/acronym interface functions and Index: doc/src/sgml/xfunc.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/xfunc.sgml,v retrieving revision 1.103 diff -u -r1.103 xfunc.sgml --- doc/src/sgml/xfunc.sgml 30 May 2005 23:09:07 - 1.103 +++ doc/src/sgml/xfunc.sgml 13 Aug 2005 19:10:55 - @@ -2778,6 +2778,16 @@ as an alternative to functionget_fn_expr_rettype/. /para +footnote + para + Information about argument and return types is generally available if + you are executing a normal function within a normal query. However, it + can be missing for implicitly used functions, such as type + input/output functions that are called directly by the planner before + the query starts. + /para +/footnote + para For example, suppose we want to write a function to accept a single element of any type, and return a one-dimensional array of that type: pgp96sslT5d75.pgp Description: PGP signature
Re: [PATCHES] [PATCH] Proposed: Have SPI_connect fail if there is no current snapshot
Martijn van Oosterhout kleptog@svana.org writes: As per discussion on -hackers, type input functions can be called prior to there being a current snapshot, causing any queries you execute to fail with the no snapshot has been set error. So I propose to simply have SPI_connect fail right off the bat and document that to avoid future surprises. This strikes me as a pretty unreasonable restriction. It would be OK if there were no valid uses of SPI that didn't require a snapshot, but that's not so. As an example, consider trying to issue a LOCK TABLE command via SPI (okay, there are other ways to do that, but it's still a valid example). regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] [PATCH] Clarify issues with SPI and C language function limitations
Martijn van Oosterhout kleptog@svana.org writes: Here is a patch to the documentation clarifying some minor issues.=20 The first is to the main SPI documentation clarifying that SPI isn't available unless there is a current snapshot (leading to the no snapshot has been set error). This is wrong. The second clarifies when the get_fn_expr_rettype() and get_fn_expr_argtype() functions can actually provide the information requested. Except it doesn't actually tell you anything very definite ... regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] For review: Server instrumentation patch
Tom Lane wrote:
I wrote:
I'll see about installing an initdb-time kluge to make it use OUT
parameters.
Done:
regression=# SELECT * FROM pg_stat_file('postgresql.conf');
length | atime | mtime | ctime
| isdir
++++---
12578 | 2005-08-13 14:51:03-04 | 2005-08-13 14:50:32-04 | 2005-08-13
14:50:32-04 | f
(1 row)
Great.
I removed the separate pg_file_length() function, as it doesn't have any
significant notational advantage anymore; you can do
Perfect. I was going to suggest that could be removed once pg_stat_file
was more usable.
regression=# select (pg_stat_file('postgresql.conf')).length;
length
12578
(1 row)
Great. I was also wondering if that would work. One more closed item!
BTW, \df is no real help when it comes to stuff with OUT parameters;
it still says
regression=# \df pg_stat_file
List of functions
Schema | Name | Result data type | Argument data types
+--+--+-
pg_catalog | pg_stat_file | record | text
(1 row)
Possibly we should try to improve that.
Good point. Let's see if people ask for it. Because they don't need to
know the data types to use the function, we might be fine.
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] PATCH to allow concurrent VACUUMs to not lock each
On R, 2005-08-12 at 15:47 -0400, Bruce Momjian wrote: This has been saved for the 8.2 release: http://momjian.postgresql.org/cgi-bin/pgpatches_hold Is there any particular reason for not putting it in 8.1 ? -- Hannu Krosing [EMAIL PROTECTED] ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] PATCH to allow concurrent VACUUMs to not lock each
Hannu Krosing wrote: On R, 2005-08-12 at 15:47 -0400, Bruce Momjian wrote: This has been saved for the 8.2 release: http://momjian.postgresql.org/cgi-bin/pgpatches_hold Is there any particular reason for not putting it in 8.1 ? I thought there was still uncertainty about the patch. Is there? -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: explain analyze is your friend
