Alvaro Herrera [EMAIL PROTECTED] writes:
I think this is done by AddRelationRawConstraints. You'd have to get
the parsetree of the default expression. I think you could get that by
applying raw_parser() to pg_attrdef.adsrc.
Not adsrc --- that's not trustworthy.
In practice I think you could
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 28 June 2005 00:58
To: Dave Page
Cc: PostgreSQL-development
Subject: Re: [HACKERS] For review: dbsize patch
Dave Page wrote:
The attached patch is an update of the dbsize integration patch
discussed
I think we still have a serious problem with multicolumn indexes. As they
stand they're basically only indexes on the first column. The later columns
are not used to determine page splits.
1. In your meaning, btree has bad split algorithm too. Look at _bt_compare, if
first keys on page are
(Sorry for the delayed response. I just got home from Germany after my
visit to Linuxtag, and I'm catching up with my -hackers email now.)
At 2005-06-25 09:30:17 -0400, pgman@candle.pha.pa.us wrote:
Hi, i have found several #ifdef NOT_USED marked code...
We keep such blocks of code around in
Tom Lane [EMAIL PROTECTED] wrote:
Yeah, this is about what I was afraid of: if you're actually fsyncing
then you get at best one commit per disk revolution, and the negotiation
with the OS is down in the noise.
If we disable writeback-cache and use open_sync, the per-page writing
behavior in
Joshua D. Drake [EMAIL PROTECTED] writes:
2005-06-27 16:37:53 ERROR: could not send data to client: Broken pipe
2005-06-27 16:37:53 PANIC: cannot abort transaction 146017848, it was
already committed
A reasonable guess as to what happened there is:
1. Client process dies just as server is
Thanks .
/D
-Original Message-
From: Andreas Pflug[EMAIL PROTECTED]
Sent: 27/06/05 22:41:35
To: Dave Pagedpage@vale-housing.co.uk
Cc: PostgreSQL-developmentpgsql-hackers@postgresql.org, Bruce
Momjianpgman@candle.pha.pa.us
Subject: Re: For review: Server instrumentation patch
Dave Page
Neil Conway wrote:
I agree the current parser is a hack, but it's difficult to see how
else it could be implemented.
Since the lexical structure of SQL/PSM seems to be about the same as the
main SQL, maybe you could get away with having the main parser just
accepting any tokens at the point
During a recent training session I was reminded about a peculiar
misbehavior that recent PostgreSQL releases exhibit when the TCP port
they are trying to bind to is occupied:
LOG: could not bind IPv4 socket: Address already in use
HINT: Is another postmaster already running on port 5432? If
[Resent as the list seems to have rejected yesterdays attempt]
As per Bruce's request, here's a copy of Andreas' server
instrumentation patch for review. I've separated out the
dbsize stuff and pg_terminate_backend is also not included.
This version was generated against CVS today.
As far as
Just a warning, because I might bring it up after feature freeze.
If we yank them ( and I agree) I think we have to do it before feature
freeze.
I believe that we have consensus to yank them. Hans says that he did
extensive testing back as far as 7.4 and the options had no effect.
On 6/28/2005 5:55 AM, Peter Eisentraut wrote:
Neil Conway wrote:
I agree the current parser is a hack, but it's difficult to see how
else it could be implemented.
Since the lexical structure of SQL/PSM seems to be about the same as the
main SQL, maybe you could get away with having the main
The valure returned from pg_config --includedir-server
is broken as of CVS.
It points to unexistent directory:
/home/extra/pgroot-cvs/include/server
Correct value would be:
/home/extra/pgroot-cvs/include/postgresql/server
--strk;
---(end of
One thing bytecode would allow us to do is to write a debugger with
break points etc.
Using a java jvm however is considerable overkill.
Dave
On 27-Jun-05, at 8:28 PM, Neil Conway wrote:
Jonah H. Harris wrote:
I don't recommend discussion for this in this thread, but it could
also tie in
Peter Eisentraut said:
During a recent training session I was reminded about a peculiar
misbehavior that recent PostgreSQL releases exhibit when the TCP port
they are trying to bind to is occupied:
LOG: could not bind IPv4 socket: Address already in use
HINT: Is another postmaster already
Jim,
you should have a file buildroot/HEAD/lastrun-logs/make.log that shows
the link steps for the libraries. Can you either put that file somewhere
we can look at it or extract the relevant lines and post in a reply?
thanks
andrew
Jim C. Nasby wrote:
I have no clue why the mailling
The attached patch integrates dbsize functions into the backend, as per
discussion on -hackers. The following functions are included:
pg_relation_size(text) - Get relation size by name/schema.name
pg_relation_size(oid)- Get relation size by OID
pg_tablespace_size(name) - Get tablespace size
On Tue, 28 Jun 2005, Dave Cramer wrote:
One thing bytecode would allow us to do is to write a debugger with
break points etc.
We can write debugger with breakpoints without bytecode. Every stmt rec
can have flag if has breakpoints. No problem. I don't see any advance of
bytecode. Maybe,
Pavel,
What do you think you need for enhanced protocol ?
Dave
On 28-Jun-05, at 8:51 AM, Pavel Stehule wrote:
On Tue, 28 Jun 2005, Dave Cramer wrote:
One thing bytecode would allow us to do is to write a debugger with
break points etc.
We can write debugger with breakpoints without
Andrew Dunstan wrote:
IIRC, in previous versions any bind failure was fatal, but in 8.0 we
decided to be slightly more forgiving and only bail out if we failed
to bind at all.
I realize that, but I would like to know where that bright idea came
from in violation of all other principles of
What do you think you need for enhanced protocol ?
What I need? Some like synchronous elog(NOTICE,''), which can return some
user's interaction, if it's possible. I didn't find how I do it with
current set of messages. But my knowleadges of protocol are minimal.
Pavel
At 2005-06-28 15:14:29 +0200, [EMAIL PROTECTED] wrote:
I recall that it had something to do with IPv6, but I'm not sure.
Under Linux, if you bind to AF_INET6/::0, a subsequent bind to AF_INET/0
will fail, but the IPv4 address is also bound by the first call, and the
program will accept IPv4
I encountered a bug where the same query behaves differently
under different LC_CTYPE settings, C and en_US.UTF-8.
The query is of type SELECT ... WHERE a like 'x' and b like 'y', where relevant
indexes exist for a and b, and 'x' and 'y' strings do not contain the %
character. When database is
Peter Eisentraut wrote:
Andrew Dunstan wrote:
IIRC, in previous versions any bind failure was fatal, but in 8.0 we
decided to be slightly more forgiving and only bail out if we failed
to bind at all.
I realize that, but I would like to know where that bright idea came
from in
On Tue, Jun 28, 2005 at 03:14:29PM +0200, Peter Eisentraut wrote:
Andrew Dunstan wrote:
IIRC, in previous versions any bind failure was fatal, but in 8.0 we
decided to be slightly more forgiving and only bail out if we failed
to bind at all.
I realize that, but I would like to know where
Alvaro Herrera wrote:
If the TCP socket is used we can still bind to the Unix-domain
socket, no?
If I configured a TCP/IP socket, what good does a Unix-domain socket do
me?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of
Andrew Dunstan wrote:
see http://archives.postgresql.org/pgsql-hackers/2004-03/msg00679.php
Well, with once release of field experience behind me I'd like to
revisit this idea. Who would actually be hurt by generating an error
here like it used to do?
--
Peter Eisentraut
Pavel Stehule [EMAIL PROTECTED] writes:
What do you think you need for enhanced protocol ?
What I need? Some like synchronous elog(NOTICE,''), which can return some
user's interaction, if it's possible. I didn't find how I do it with
current set of messages. But my knowleadges of protocol
Peter Eisentraut [EMAIL PROTECTED] writes:
During a recent training session I was reminded about a peculiar
misbehavior that recent PostgreSQL releases exhibit when the TCP port
they are trying to bind to is occupied:
LOG: could not bind IPv4 socket: Address already in use
HINT: Is
Abhijit Menon-Sen [EMAIL PROTECTED] writes:
We keep such blocks of code around in case we might need to use it
some day.
I think that's a bad idea. Unused code should be removed with a suitable
CVS checkin comment (and perhaps a comment where the code was),
The code is that comment. Mostly,
After the recent role-capable catalog commit, initdb -W fails with
the following error:
initializing pg_authid ... ok
Enter new superuser password:
Enter it again:
setting password ... ok
initdb: The password file was not generated. Please report this problem.
initdb: removing contents of data
Michael Fuhr [EMAIL PROTECTED] writes:
After the recent role-capable catalog commit, initdb -W fails with
the following error:
initializing pg_authid ... ok
Enter new superuser password:
Enter it again:
setting password ... ok
initdb: The password file was not generated. Please report
Dmitry Karasik [EMAIL PROTECTED] writes:
When database is initdb'ed with LC_CTYPE=C, the query uses index
scan; when LC_CTYPE=en_US.UTF-8 it is the sequential scan.
This is in the FAQ:
When using wild-card operators such as LIKE or ~, indexes can only be
used in certain circumstances:
On Tue, 28 Jun 2005, Tom Lane wrote:
Pavel Stehule [EMAIL PROTECTED] writes:
What do you think you need for enhanced protocol ?
What I need? Some like synchronous elog(NOTICE,''), which can return some
user's interaction, if it's possible. I didn't find how I do it with
current set
Tatsuo Ishii [EMAIL PROTECTED] writes:
If we yank them ( and I agree) I think we have to do it before feature
freeze.
I believe that we have consensus to yank them. Hans says that he did
extensive testing back as far as 7.4 and the options had no effect.
My opinion is, we'd better test
On Tue, Jun 28, 2005 at 10:35:43AM -0400, Tom Lane wrote:
Tatsuo Ishii [EMAIL PROTECTED] writes:
If we yank them ( and I agree) I think we have to do it before feature
freeze.
I believe that we have consensus to yank them. Hans says that he did
extensive testing back as far as 7.4
Christopher Browne [EMAIL PROTECTED] writes:
There are essentially four choices:
Aside:
I suppose there are as many possible choices as there are bytecode
compiled systems out there. One could consider Icon, CLISP, Python,
PHP, OCAML, CMU/CL, all of which have bytecode compilers.
But none of
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
Attached please find files and patches associated with moving from the
User/Group system currently in place to Roles, as discussed
previously.
I have cleaned this up a bit and committed it. I normally
I'm seeing the following failure on win32, post roles patch application:
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wold-style-definition -Wendif-labels
-fno-strict-aliasing -I../../../src/include -I./src/include/port/win32
-DEXEC_BACKEND
* Tom Lane ([EMAIL PROTECTED]) wrote:
The SQL99 spec has for GRANT (REVOKE has the identical issue):
grant privilege statement ::=
GRANT privileges
TO grantee [ { comma grantee }... ]
[ WITH HIERARCHY OPTION ]
[
Pavel,
I am in agreement with Tom here, we should use a separate port, and
protocol specifically designed for this.
My understanding is that this protocol would be synchronous, and be
used for transferring state information, variables, etc back and forth
whereas the existing protocol would
Tom Lane wrote:
What behavior are you proposing, exactly?
The least thing it should do is error out if *no* TCP/IP port could be
created while listen_addresses is set.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of
I'm looking at the problem Stephen Frost noted of not being able to
duplicate the SQL99-specified syntax for GRANT/REVOKE with roles.
The SQL99 spec has for GRANT (REVOKE has the identical issue):
grant privilege statement ::=
GRANT privileges
TO grantee [
* Michael Fuhr ([EMAIL PROTECTED]) wrote:
After the recent role-capable catalog commit, initdb -W fails with
the following error:
Whoops, sorry about that, didn't know initdb had a -W option. :)
Thanks,
Stephen
signature.asc
Description: Digital signature
All the logs for the most recent run against HEAD are now at
http://stats.distributed.net/~buildfarm/
On Tue, Jun 28, 2005 at 08:30:44AM -0400, Andrew Dunstan wrote:
Jim,
you should have a file buildroot/HEAD/lastrun-logs/make.log that shows
the link steps for the libraries. Can you
Hi Fabien,
* Fabien COELHO ([EMAIL PROTECTED]) wrote:
I've looked very quickly at the patch. ISTM that the proposed patch is a
reworking of the user/group stuff, which are both unified for a new role
concept where a user is a kind of role and a role can be a member of
another role. Well,
Tom,
Incidentally, I have tests in the queue. It's just that the STP has been
very unreliable for the last month so I've not been able to get definitive
test results.
More important than commit_*, is, of course the WAL/CRC stuff for
checkpoint cost, which I'm also getting impatient to test.
Joshua D. Drake [EMAIL PROTECTED] writes:
Do you know what the dead client was doing?
Unfortunately I don't. We didn't have PID logging turned on so I can't
tell which process it was. The only thing I was told was,
I am running a Full Vacuum, CRAP the server just died ;)
Hmm ... VACUUM FULL
Dave Page dpage@vale-housing.co.uk writes:
../../../src/include/utils/acl.h:214: error: conflicting types for
'InitializeAcl'
c:/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../include/winbase.h:1571
: error: previous declaration of 'InitializeAcl' was here
Grumble. I'll change the routine
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
What behavior are you proposing, exactly?
The least thing it should do is error out if *no* TCP/IP port could be
created while listen_addresses is set.
That might be reasonable --- I think right now we only die if we
couldn't create
Stephen Frost [EMAIL PROTECTED] writes:
Is there some way we could use that 'ON' is required for the
'privileges' grant?
Well, the difficulty is that we can't see the ON until we've scanned
the list of privilege or role names. Now that I've calmed down a bit,
the solution is fairly obvious:
Stephen Frost [EMAIL PROTECTED] writes:
Also, I've been looking through the diff between my tree and what you
committed to CVS and had a couple comments
First, sorry about the gratuitous name changes, it helped me find
every place I needed to look at the code and think about if it needed
There are a couple of big problems with this theory, though. In the
first place, there aren't any messages sent to the client during
post-commit; unless possibly it's an error message due to a failure
during post-commit, and that should have shown up in the server log.
In the second place, we
* Dave Page (dpage@vale-housing.co.uk) wrote:
I'm seeing the following failure on win32, post roles patch application:
[...]
'InitializeAcl'
[...]
That's following a cvs update and a make clean. All was fine before I
updated :-(
Wow. Apparently 'InitializeAcl' is part of the Windows API. My
Stephen Frost [EMAIL PROTECTED] writes:
The code I had for this was:
if (!pg_class_ownercheck(tuple,GetUserId()) ||
!is_role_member(newowner,GetUserId()))
That needs a check for superuser though because while the test will pass
on the 'pg_class_ownercheck' side, it won't on the
Folks,
There's no time to do this for 8.1, but I'd like to get it on the books for
8.2:
The Problem: Occassionally a DBA needs to dump a database to a new
encoding. In instances where the current encoding, (or lack of an
encoding, like SQL_ASCII) is poorly supported on the target database
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
What behavior are you proposing, exactly?
The least thing it should do is error out if *no* TCP/IP port could be
created while listen_addresses is set.
That might be reasonable --- I think
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
Second, looks like I missed fixing an owner check in pg_proc.c
Got it. I was wondering if there were more --- might be worth checking
all the superuser() calls.
Yeah, let's come up with a decision about what
Teodor Sigaev [EMAIL PROTECTED] writes:
1. In your meaning, btree has bad split algorithm too. Look at _bt_compare, if
first keys on page are unique the the later keys will not be compared ;)
I'm confused now. I was under the impression that gist didn't look at
subsequent columns if the first
Jim C. Nasby wrote:
All the logs for the most recent run against HEAD are now at
http://stats.distributed.net/~buildfarm/
A quick look shows that when you use --with-libraries=/foo/bar the
generated link line for libraries says
-L/foo/bar -lpq
and it should probably be the other
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
That needs a check for superuser though because while the test will pass
on the 'pg_class_ownercheck' side, it won't on the 'is_role_member' side
Um, right, that was another problem I had with it --- at one point
Tom Lane wrote:
I'm looking at the problem Stephen Frost noted of not being able to
duplicate the SQL99-specified syntax for GRANT/REVOKE with roles.
The SQL99 spec has for GRANT (REVOKE has the identical issue):
grant privilege statement ::=
GRANT privileges
-Original Message-
From: Stephen Frost [mailto:[EMAIL PROTECTED]
Sent: 28 June 2005 18:30
To: Dave Page
Cc: PostgreSQL-development
Subject: Re: [HACKERS] CVS tip build failure (win32)
* Dave Page (dpage@vale-housing.co.uk) wrote:
I'm seeing the following failure on win32,
On Tue, 28 Jun 2005, Josh Berkus wrote:
The TODO: add an --encoding=[encoding name] option to pg_dump. This would
set client_encoding for pg_dump's session(s).
What about just using the PGCLIENTENCODING environment variable?
Kris Jurka
---(end of
Josh Berkus wrote:
currently the only way to set the encoding of a pg_dump file is to
change client_encoding in postgresql.conf and restart postmaster.
Another way is to set the environment variable PGCLIENTENCODING.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
On Tue, Jun 28, 2005 at 14:45:06 -0400,
Stephen Frost [EMAIL PROTECTED] wrote:
If you are the owner of the object to be changed (following the normal
owner checking rules) AND would still be considered the owner of the
object *after* the change, then you can change the ownership.
That
On Tue, Jun 28, 2005 at 14:52:07 -0500,
Bruno Wolff III [EMAIL PROTECTED] wrote:
On Tue, Jun 28, 2005 at 14:45:06 -0400,
Stephen Frost [EMAIL PROTECTED] wrote:
If you are the owner of the object to be changed (following the normal
owner checking rules) AND would still be considered
Stephen Frost wrote:
I can perhaps see a special case for SECURITY DEFINER functions but if
we're going to special case them I'd think we'd need to make them only
be creatable/modifiable at all by superusers or add another flag to the
role to allow that.
I agree that owner changes of SECURITY
* Bruno Wolff III ([EMAIL PROTECTED]) wrote:
On Tue, Jun 28, 2005 at 14:45:06 -0400,
Stephen Frost [EMAIL PROTECTED] wrote:
If you are the owner of the object to be changed (following the normal
owner checking rules) AND would still be considered the owner of the
object *after* the
There's no time to do this for 8.1, but I'd like to get it on
the books for
8.2:
The Problem: Occassionally a DBA needs to dump a database to a new
encoding. In instances where the current encoding, (or lack of an
encoding, like SQL_ASCII) is poorly supported on the target
database
Stephen Frost wrote:
If you're considered the owner of an object then you have access to drop
it already. You have to be a member of the role to which you're
changing the ownership. That role not having permission to create the
object in place is an interesting question. That's an issue for
* Bruno Wolff III ([EMAIL PROTECTED]) wrote:
Thinking about it some more, drops wouldn't be an issue since the owner
can always drop objects.
Right.
Creating objects in particular schemas or databases is not something that
all roles may be able to do.
Yeah, I'm not entirely sure what I
On Tue, Jun 28, 2005 at 10:24:19PM +0200, Magnus Hagander wrote:
I *think* that's easy enough to do in time for 8.1. Trivial patch
attached. I hope it's enough :-) It passed my very quick testing...
(Yup, I read the mails aobut PGCLIENTENCODING, but an option to pg_dump
is certainly easier)
I *think* that's easy enough to do in time for 8.1. Trivial patch
attached. I hope it's enough :-) It passed my very quick testing...
(Yup, I read the mails aobut PGCLIENTENCODING, but an option to
pg_dump is certainly easier)
You forgot to document the long option, I think.
Oops.
I *think* that's easy enough to do in time for 8.1. Trivial patch
attached. I hope it's enough :-) It passed my very quick testing...
(Yup, I read the mails aobut PGCLIENTENCODING, but an option to
pg_dump is certainly easier)
You forgot to document the long option, I think.
Are
Alvaro Herrera wrote:
On Tue, Jun 28, 2005 at 10:24:19PM +0200, Magnus Hagander wrote:
I *think* that's easy enough to do in time for 8.1. Trivial patch
attached. I hope it's enough :-) It passed my very quick testing...
(Yup, I read the mails aobut PGCLIENTENCODING, but an option to
* Michael Paesold ([EMAIL PROTECTED]) wrote:
Stephen Frost wrote:
If you're considered the owner of an object then you have access to drop
it already. You have to be a member of the role to which you're
changing the ownership. That role not having permission to create the
object in place is
--On Dienstag, Juni 28, 2005 09:38:56 +0800 Christopher Kings-Lynne
[EMAIL PROTECTED] wrote:
Does ALTER TABLE/RENAME code help you? You can rename sequences with
that...
Hmm, that doesn't cover pg_attrdef.adbin. I think the best way is to create
the default expressions from scratch, as Tom
--On Dienstag, Juni 28, 2005 02:01:33 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
Not adsrc --- that's not trustworthy.
Yes, that's documented in the docs, too.
In practice I think you could just assume you know what the default
expression ought to be, and store a new one without looking at
On Tue, 28 Jun 2005, Dave Cramer wrote:
Pavel,
I am in agreement with Tom here, we should use a separate port, and
protocol specifically designed for this.
My understanding is that this protocol would be synchronous, and be
used for transferring state information, variables, etc back
Dave,
I lean with you and Tom. While running it over the same libpq protocol
would be helpful in some ways, it would have a lot of drawbacks and
would really change the function of libpq. I think a separate debugging
protocol is in order.
Also, as far as bytecode comments go, let's
Stephen Frost [EMAIL PROTECTED] writes:
* Bruno Wolff III ([EMAIL PROTECTED]) wrote:
Creating objects in particular schemas or databases is not something that
all roles may be able to do.
Yeah, I'm not entirely sure what I think about this issue.
We have a precedent, which is that RENAME
Title: Re: [HACKERS] Implementing SQL/PSM for PG 8.2 - debugger
I'm psyched for EDB to particpate and/or in some way sponsor this effort. How can we best help to make this a reality sooner rather than later??
There's going to be a painful period later this year when Mysqueel is
I lean with you and Tom. While running it over the same libpq protocol
would be helpful in some ways, it would have a lot of drawbacks and
would really change the function of libpq. I think a separate debugging
protocol is in order.
One message? I can't belive :).
work on it (ANTLR
There's going to be a painful period later this year when Mysqueel
is able to claim that their production db has more ansi compatability
than PG (at least for triggers and stored procs).
MySQL5 is really comparable with Pg8, but Firebird2 or SQLlite3 too. But
from my perspective procedural
On Tue, Jun 28, 2005 at 12:29:22PM -0400, Tom Lane wrote:
One objection to this is that misspelling a privilege keyword would
give you a complaint about unknown role, which might be a bit
confusing; but I suspect we cannot avoid that anyway --- there is
absolutely no basis on which we can say
Dave Page wrote:
Dave Page wrote:
The attached patch is an update of the dbsize integration patch
discussed last week. This version includes the following functions:
pg_relation_size(text) - Get relation size by name/schema.name
pg_relation_size(oid)- Get relation size by
strk wrote:
The valure returned from pg_config --includedir-server
is broken as of CVS.
It points to unexistent directory:
/home/extra/pgroot-cvs/include/server
Correct value would be:
/home/extra/pgroot-cvs/include/postgresql/server
Well, on my system on CVS is right:
$
On Tue, Jun 28, 2005 at 02:28:11PM -0400, Andrew Dunstan wrote:
Jim C. Nasby wrote:
All the logs for the most recent run against HEAD are now at
http://stats.distributed.net/~buildfarm/
A quick look shows that when you use --with-libraries=/foo/bar the
generated link line
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
* Bruno Wolff III ([EMAIL PROTECTED]) wrote:
Creating objects in particular schemas or databases is not something that
all roles may be able to do.
Yeah, I'm not entirely sure what I think about this issue.
Dave Page wrote:
The attached patch integrates dbsize functions into the backend, as per
discussion on -hackers. The following functions are included:
pg_relation_size(text) - Get relation size by name/schema.name
pg_relation_size(oid)- Get relation size by OID
[ pick up new version.]
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
Here are our open items. How hard are we going to be about the cutoff
date? Do we give people the weekend to complete some items?
---
PostgreSQL 8.1 Open Items
I would like to write a postgres extension type which represents a btree of data
and allows me to access and modify elements within that logical btree. Assume
the type is named btree_extension, and I have the table:
CREATE TABLE example (
a TEXT,
b TEXT,
c
* Bruce Momjian (pgman@candle.pha.pa.us) wrote:
Here are our open items. How hard are we going to be about the cutoff
date? Do we give people the weekend to complete some items?
Changes
---
[...]
I'm not sure what else Tom's already working on wrt roles, but I plan to
send in the
On Tue, Jun 28, 2005 at 07:38:43PM -0700, Mark Dilger wrote:
I would like to write a postgres extension type which represents a btree of
data and allows me to access and modify elements within that logical btree.
Assume the type is named btree_extension, and I have the table:
CREATE TABLE
How about enable/disable triggers?
From TODO:
Allow triggers to be disabled.
http://momjian.postgresql.org/cgi-bin/pgtodo?trigger
I think this is good for COPY performance improvement.
Now I have user functions to enable/disable triggers, not DDL.
It modifies system tables.
But I can rewrite
On Tue, 28 Jun 2005, Bruce Momjian wrote:
Here are our open items. How hard are we going to be about the cutoff
date? Do we give people the weekend to complete some items?
Sounds reasonable to me ... Always hate doing stuff like this on a Friday
myself ...
Bernd Helmle [EMAIL PROTECTED] writes:
Whats the least that should go to -patches for
feature release on 1 July (only to know, if i can hold timeline or not).??
Something reasonably complete, working, credible. We'll cut you slack
on documentation changes and regression tests, and if it has a
Is it possible for a pl/pgsql trigger function to look at the sql
command that caused it to be triggered? If not, is this an idea?
Chris
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
1 - 100 of 110 matches
Mail list logo
