Several years ago me and Teodor have proposed partial sort for
top-k ranking result. We have even submitted a very crude patch, but it was
rejected. We use partial sorting extensively in our external application
and found it's very useful. There are many papers recently published about
top-k proble
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 thing
to work reliably. I thought the point of \d formatting was to be
readable, not to be technically the exact same SQL you'd need to enter.
Hm, I always assu
Tom Lane <[EMAIL PROTECTED]> writes:
> 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 thing
> to work reliably. I thought the point of \d formatting was to be
> readable, not to be technically the exact
Kind people,
I just ran across this, and was wondering whether it's worth a
back-patch. The interval type has an aggregate for average (AVG), but
not one for standard deviation (STDDEV) or variance (VARIANCE).
Is this a bug? Is there some problem with defining variance over
intervals?
TIA 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 thin
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 optio
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 o
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 [EMA
#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
-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 vers
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 "
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 psql
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
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'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
--
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 Sq
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. I
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
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_dum
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
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 an
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
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; -- com
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-
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 some
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 somep
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
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 whe
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.
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 r
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
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 r
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 compat
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
34 matches
Mail list logo
