On 7/10/2004 10:54 AM, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Do we want to add this to TODO:
* Issue an extra message when COMMIT completes a failed transaction
No --- it's (a) wordy and (b) not responsive to the original complaint,
which was that a
Jan Wieck [EMAIL PROTECTED] writes:
Either changing the command tag or let COMMIT of an aborted transaction
fail (and stay in aborted transaction state). Those are the only two
clean ways to communicate to the client no, I cannot commit.
Well, the latter would *certainly* create
Alvaro Herrera [EMAIL PROTECTED] writes:
On Sat, Jul 10, 2004 at 09:18:28PM -0700, elein wrote:
The new plperl returns sets by having
the function return an array.
I think RETURN NEXT does the same thing anyway ... they just store
tuples in a Tuplestore and then the whole thing is returned.
Scott,
Uh, I think it can:
http://www.php.net/manual/en/function.pg-result-error.php
Heh. I half-knew that if I pointed this out that someone would correct me
with a link to new code. In my defense, I will point out that the mentioned
PHP feature is less than 4 months old.
Not a real
Bruce,
Do we want to allow BEGIN NESTED to start a main transaction? Oracle
can use SAVEPOINTS all the time because it knows it is always in a
transaction, but PostgreSQL is not always. I don't see a downside to
allowing it. COMMIT will still commit the entire transaction, of
course.
Alvaro,
I have a better question: do we allow SAVEPOINT (i.e. to establish a
savepoint, i.e. to open a nested transaction) within an aborted
transaction block?
My opinion? No. I would personally not want to allow it.
My opinion is that we should disallow both SAVEPOINT and RELEASE when
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I also don't see LOG used much in the code at all. It seems to be used
mostly by VACUUM and ANALYZE. Seems something is wrong.
There is nothing wrong except that you've forgotten how we designed
VACUUM VERBOSE to work with the new
On Sun, 2004-07-11 at 16:01, Josh Berkus wrote:
Scott,
Uh, I think it can:
http://www.php.net/manual/en/function.pg-result-error.php
Heh. I half-knew that if I pointed this out that someone would correct me
with a link to new code. In my defense, I will point out that the
I have updated the /contrib/mysql/README file to point to the new URL's.
Thanks.
---
Robert Treat wrote:
I don't see the old link you are referring to (and neither did grep); is
this on the main page of techdocs or
I'll try these in plperl when I get a chance, but there is still
a scalability problem.
There was some work done at UCB a while back (post-postgres)
to try to speed up queries by making the first n rows available
quickly. This is based on the googlish idea that people want
results fast and
Were are we on deciding how PREPARE in aborted transactions should behave?
---
Greg Sabino Mullane wrote:
[ There is text before PGP section. ]
[ PGP not available, raw data follows ]
-BEGIN PGP SIGNED MESSAGE-
On Sun, Jul 11, 2004 at 03:15:46PM -0700, Josh Berkus wrote:
For that matter:
begin;
savepoint;
select 0/0; -- abort
savepoint; -- commands will be ignored
select 1; -- commands will be ignored
release; -- commands
Alvaro Herrera wrote:
On Sun, Jul 11, 2004 at 03:15:46PM -0700, Josh Berkus wrote:
For that matter:
begin;
savepoint;
select 0/0; -- abort
savepoint; -- commands will be ignored
select 1; -- commands will be ignored
Bruce Momjian wrote:
If you get full control of PostgreSQL, you can dictate what will happen.
Until then, I will follow the community consensus, which may or may not
match your opinion.
Um, let's take the time to get the features in, otherwise we'll be
waiting another year (roughly) to get PITR
I can do that for 7.6. Is it worth it? Is it a TODO?
---
Christopher Kings-Lynne wrote:
As a result of the constraint output functions being shared between
pg_dump and psql, some of the output is mis-quoted in the
Andreas Joseph Krogh wrote:
[ PGP not available, raw data follows ]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi, I've prepared a patch(against CVS HEAD of today) to pg_dump.c to
make pg_dump understand multiple -t options for dumping multiple tables
in one command.
Eks:
pg_dump -t
On Sun, 2004-07-11 at 20:57, Bruce Momjian wrote:
I can do that for 7.6. Is it worth it? Is it a TODO?
I'm not sure what Christopher mentioned is the correct fix. The
information is displayed correctly in all places except where a
pg_get_.* function is used (indexes, constraints, etc.).
Those
I have caught up with my email and have loaded the patches queue with
everything that was submitted before the feature freeze:
http://momjian.postgresql.org/cgi-bin/pgpatches
It is going to take some time to work through these patches and get them
all applied, but we are working on it.
Are we removing initlocation in 7.5 now that we have tablespaces?
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown
I'm not sure what Christopher mentioned is the correct fix. The
information is displayed correctly in all places except where a
pg_get_.* function is used (indexes, constraints, etc.).
The name of the constraint (ie. the $1 bit) is done by psql, the rest
comes from the pg_get_function.
Chris
It should be done, otherwise you cannot copy and paste foreign key
creation code from the psql output :)
Chris
Bruce Momjian wrote:
I can do that for 7.6. Is it worth it? Is it a TODO?
---
Christopher Kings-Lynne wrote:
As
I remember a thread about pretty-print functions. Are those used? This
is probably the best place to put the fix, since they already munge
things for display purposes.
On Sun, 2004-07-11 at 21:33, Christopher Kings-Lynne wrote:
It should be done, otherwise you cannot copy and paste foreign key
I remember a thread about pretty-print functions. Are those used? This
is probably the best place to put the fix, since they already munge
things for display purposes.
Seriously man - the pg_get_def stuff ONLY does the string from the words
FOREIGN KEY onwards. The constraint name is done by
On Sun, 2004-07-11 at 21:34, Christopher Kings-Lynne wrote:
I'm not sure what Christopher mentioned is the correct fix. The
information is displayed correctly in all places except where a
pg_get_.* function is used (indexes, constraints, etc.).
The name of the constraint (ie. the $1 bit)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
To my current knowledge (and hopefully Andrew will speak up if I'm
wrong) the DBD::Pg driver reports back a query exception, but not
the SQLSTATE.
The current production driver will report back the error, but not the
SQLSTATE. The next
#timezone = unknown # actually, defaults to TZ environment
setting
Is that comment still actually true?
Chris
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Bruce Momjian [EMAIL PROTECTED] writes:
Are we removing initlocation in 7.5 now that we have tablespaces?
It's long gone ...
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
It should be done, otherwise you cannot copy and paste foreign key
creation code from the psql output :)
Since when was that a design goal for psql's \d output? We had better
revert the entire pretty-printing patch if you expect this sort of
On Sun, 2004-07-11 at 19:00, Bruce Momjian wrote:
Andreas Joseph Krogh wrote:
[ PGP not available, raw data follows ]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi, I've prepared a patch(against CVS HEAD of today) to pg_dump.c to
make pg_dump understand multiple -t options for
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
#timezone = unknown # actually, defaults to TZ environment
setting
Is that comment still actually true?
Yes, we do still believe TZ if it is set; see select_default_timezone.
The comment isn't the whole story, but I don't think it
30 matches
Mail list logo
