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(
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
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
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]:
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
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
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
*
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
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|
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.
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
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
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
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,
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:
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,
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
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
[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
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
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
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
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
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.
24 matches
Mail list logo
