* Proposed changes to allow amgetnext to return the actual index keys,
allowing certain types of unindexable quals to be checked without
having to fetch the heap entry. For example a LIKE condition could be
fully checked against the index entry.
In the extreme we could build tuples and
On Thu, 10 Apr 2008, Brendan Jurd wrote:
[Automatic e-mail notification] is trivial to configure in a real
tracker. Less so for a wiki page, but it could still be accomplished
with the careful application of script-fu.
Anyone who is interested can sign up for e-mail notification whenever a
Bruce Momjian wrote:
Fine with me, but I was hoping someone would come up with an idea that
would reduce what I need to do, like perhaps a new vacuum cleaner. ;-
Bruce et al.,
If you need a reasonably (modestly?) intelligent person to put to work
helping, I am more than willing to work
Brendan Jurd [EMAIL PROTECTED] writes:
The typical way to solve this is to have the tracker send an automatic
notification email to a list saying Hey, there's a new ticket at ,
come and check it out.
Unfortunately that is the typical way to solve this. And it's awful.
It's like the
On Thu, 2008-04-10 at 05:03 +0930, Shane Ambler wrote:
I do think it is useful for more than typo's in the \join command. What
about a slip where you forget to \g the command. Or you start a query
that seems to be taking too long, background it and look into what is
happening. This would be
Gregory Stark wrote:
Brendan Jurd [EMAIL PROTECTED] writes:
The typical way to solve this is to have the tracker send an automatic
notification email to a list saying Hey, there's a new ticket at ,
come and check it out.
Unfortunately that is the typical way to solve this. And it's awful.
I find myself doing this frequently with any long-running command,
but currently it's a PITA because I'd doing it at the shell level and
firing up a new psql: more work than should be necessary, and psql
sometimes gets confused when you resume it from the background in
interactive
Thanks for the response. Below are the details:
On Wed, 2008-04-09 at 18:33 +0530, Ashish Sharma wrote:
Hi,
Hi, all!!
The setup in question includes PostGRESQL v8.2.4, Java based web
servers and MS.NET based web servers. Following is the fuzzy
situation:
Csaba Nagy [EMAIL PROTECTED] writes:
For interactive use in the above mentioned scenario you can use the
'screen' command and start as many psqls as needed
Sure, or you could just start multiple xterms or emacs shell buffers
(my preferred setup).
But I'm sure there are people who would
On Thu, Apr 10, 2008 at 1:07 PM, Gregory Stark [EMAIL PROTECTED] wrote:
The typical way to solve this is to have the tracker send an automatic
notification email to a list saying Hey, there's a new ticket at ,
come and check it out.
Unfortunately that is the typical way to solve this.
On Thu, Apr 10, 2008 at 3:03 PM, Stefan Kaltenbrunner
[EMAIL PROTECTED] wrote:
well what about having the tracker being subscribed to the list and let it
create a bug/patch/ticket id automatically for new mails - that way all
stuff is automatically tracked ? - That way it can be categorized
Is there any patch available for this one?
I'm encountering troubles with some JDBC queries and I'd like to test
it before asking some help on the JDBC list.
Thanks.
Tom
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Tom Lane schrieb:
Jonah H. Harris [EMAIL PROTECTED] writes:
I've run into a couple cases now where it would be helpful to easily
assign an already-existing unique index as a primary key.
You need to present a more convincing use-case than this unsupported
assertion. There's hardly
* Proposed change to let both amgetnext and amgetmulti mark returned
tuples as candidate matches, that is in need of rechecking of quals
indexes). There seemed to be some possible marginal use for it in GIST
indexes, but I'm not convinced that's a sufficient reason to complicate
the APIs.
On Thu, Apr 10, 2008 at 3:41 PM, Gregory Stark [EMAIL PROTECTED] wrote:
What's wrong with a patch submitter submitting a patch to a tracker,
but then emailing the list for actual discussion?
What's what we have today with the wiki. We don't need any special software
to
do that. It
It's pretty easy to test.
prepare the query
and
run explain analyze on the prepared statement.
Dave
On 10-Apr-08, at 5:47 AM, Thomas Burdairon wrote:
Is there any patch available for this one?
I'm encountering troubles with some JDBC queries and I'd like to
test it before asking some help
Tom Dunstan wrote:
On Thu, Apr 10, 2008 at 1:07 PM, Gregory Stark [EMAIL PROTECTED] wrote:
The typical way to solve this is to have the tracker send an automatic
notification email to a list saying Hey, there's a new ticket at ,
come and check it out.
Unfortunately that is the typical
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Tom Dunstan wrote:
What's wrong with a patch submitter submitting a patch to a tracker,
but then emailing the list for actual discussion?
What's what we have today with the wiki. We don't need any special software to
do that. It does require
Tom Dunstan wrote:
On Thu, Apr 10, 2008 at 3:03 PM, Stefan Kaltenbrunner
[EMAIL PROTECTED] wrote:
well what about having the tracker being subscribed to the list and let it
create a bug/patch/ticket id automatically for new mails - that way all
stuff is automatically tracked ? - That way it
PFC wrote:
About the FSM :
Would it be possible to add a flag marking pages where all tuples
are visible to all transactions ? (kinda like frozen I think)
Ah, the visibility map. That's another line of discussion. The current
plan is to not tie that to the FSM, but implement it
* Dumb Optimization #1:
- Add executorFunc function pointer to struct PlanState
- in ExecProcNode.c - ExecProcNode() :
- upon first execution, set executorFunc to the function corresponding to
node type
- next calls use function pointer
Effect : removes a switch
Hannu Krosing wrote:
On Wed, 2008-04-09 at 21:09 +0300, Heikki Linnakangas wrote:
Hannu Krosing wrote:
Saving 1 byte is an atomic op
Unfortunately, it's not. Most if not all modern CPUs will perform one
byte modification as load word + modify word + save word.
Hmm, maybe we I should change
Joshua D. Drake escribió:
On Wed, 09 Apr 2008 23:01:30 -0300
Marc G. Fournier [EMAIL PROTECTED] wrote:
I could see it with older submitters, who are used to just sending an
email, but the new guys will go with whatever procedure is laid out
for them *as long as* it is enforced ...
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
What parts of PGconn/PGresult do you need to touch that aren't exposed
already?
Don't need direct access to PGconn at all.
Oh, good, that makes things much easier.
Shoot! Feels like you always miss something.
The patch uses
Am Samstag, 5. April 2008 schrieb Gregory Stark:
Regardless of whether we go ahead with this (and I'm not fond of it
primarily because I want \c to work), I think we would still be better
off keeping the aliases in a separate namespace from psql commands and
having an explicit command for
Stefan Kaltenbrunner wrote:
well what about having the tracker being subscribed to the list and let
it create a bug/patch/ticket id automatically for new mails - that way
all stuff is automatically tracked ? - That way it can be categorized in
the course of the following discussion but
Tom Lane escribió:
Obviously there are virtues on both sides of this, which is why I think
we need both mechanisms. The simplest way to integrate them AFAICS
is to use the tracker as an index on the email traffic.
Agreed.
--
Alvaro Herrera
Martin Edlman wrote:
| I don't want to rewrite whole trigger to plPerl as I would have to use
| DBD-PgSPI.
|
| Huh? Certainly not -- there are functions in PL/Perl for this. See
| spi_exec_query in
| http://www.postgresql.org/docs/8.3/static/plperl-database.html
Oh, I see. I have read
Peter Eisentraut [EMAIL PROTECTED] writes:
But other people do want to use it. If it is too confusing for you, don't
use
it. That's what's nice about this feature: If you don't use it, it doesn't
affect you at all.
Ah but I would use it. In particular the query I found myself writing
Alvaro Herrera wrote:
Stefan Kaltenbrunner wrote:
well what about having the tracker being subscribed to the list and let
it create a bug/patch/ticket id automatically for new mails - that way
all stuff is automatically tracked ? - That way it can be categorized in
the course of the
Andrew Chernow [EMAIL PROTECTED] writes:
Shoot! Feels like you always miss something.
The patch uses PGconn's PQExpBuffer to set errors on a conn. Currently, there
is no access to this buffer other than PQerrorMessage. Is the below okay?
Surely you would just provide a function to get
Gregory Stark wrote:
Bug/request trackers are great tools, but they're just tools. They don't
replace actually having to do the work. Given the really trivial number of
patches we're dealing with really just adding entries to a wiki page is a
perfectly reasonable solution.
+1
--
Alvaro
Andrew Dunstan wrote:
The consensus last year among a group of us who examined a number of
tracker systems was, IIRC, that Bugzilla had the best combination of
features that people had requested. (And it does have some email
interaction). Stefan Kaltenbrunner did some work on putting up a
Gregory Stark wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
Shoot! Feels like you always miss something.
The patch uses PGconn's PQExpBuffer to set errors on a conn. Currently, there
is no access to this buffer other than PQerrorMessage. Is the below okay?
Surely you would just provide
Alvaro Herrera wrote:
Andrew Dunstan wrote:
The consensus last year among a group of us who examined a number of
tracker systems was, IIRC, that Bugzilla had the best combination of
features that people had requested. (And it does have some email
interaction). Stefan Kaltenbrunner did some
Andrew Dunstan wrote:
Alvaro Herrera wrote:
Stefan Kaltenbrunner wrote:
well what about having the tracker being subscribed to the list and
let it create a bug/patch/ticket id automatically for new mails -
that way all stuff is automatically tracked ? - That way it can be
categorized
On Thu, 10 Apr 2008 09:29:10 -0400
Andrew Dunstan [EMAIL PROTECTED] wrote:
The issue frankly is not tracker features. The issue is who is going
to maintain it, doing pruning and triage as necessary. No tracker
looks after itself.
If you provide a reasonable interface to management
On Thu, 10 Apr 2008 09:36:23 -0400
Alvaro Herrera [EMAIL PROTECTED] wrote:
Gregory Stark wrote:
Bug/request trackers are great tools, but they're just tools. They
don't replace actually having to do the work. Given the really
trivial number of patches we're dealing with really just
Andrew Dunstan wrote:
Magnus Hagander wrote:
I just tried the MSVC build on a system with ActiveState Perl 5.10,
and it doesn't work. Some quick debugging before I downgraded to
5.8 showed that this regexp in Project.pm line 262:
my $replace_re =
Joshua D. Drake wrote:
On Thu, 10 Apr 2008 09:36:23 -0400
Alvaro Herrera [EMAIL PROTECTED] wrote:
Gregory Stark wrote:
Bug/request trackers are great tools, but they're just tools. They
don't replace actually having to do the work. Given the really
trivial number of patches we're
Gregory Stark escribió:
Ah but I would use it. In particular the query I found myself writing *all*
the time over and over again in Oracle was:
select count(*),n from (select count(*) as n from tab group by col) group
by n
I can type it out now from finger-memory without even thinking
Am Donnerstag, 10. April 2008 schrieb Tom Dunstan:
Even so I reckon
that would create vastly more noise than signal in the eventual
tracker - part of the existing problem has been that wading through
list archives is a pain for someone wanting to know the current status
of a patch. I can't
I guess I'll keep talking to myself, but...
Le mercredi 02 avril 2008, Dimitri Fontaine a écrit :
My previous tests were only done with REL8_2_STABLE cvs branch, I just
redone some tests with REL8_3_STABLE and got no error. The index is still
buggy, in the sense some requests returns different
Am Donnerstag, 10. April 2008 schrieb Andrew Dunstan:
The issue frankly is not tracker features. The issue is who is going to
maintain it, doing pruning and triage as necessary.
I'll do it. Now just give me one I can maintain.
--
Sent via pgsql-hackers mailing list
So, Greg, after all this feedback, are you going to rework the patch?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Thu, 10 Apr 2008 10:15:29 -0400
Alvaro Herrera [EMAIL PROTECTED] wrote:
I don't think so because it really isn't a change from what we have
now. There isn't much difference from having a wiki page versus just
having conversations on the patch list and moving email around.
If you don't
Am Donnerstag, 10. April 2008 schrieb Stefan Kaltenbrunner:
the setup is more or less complete and the integration part was with the
community login system (same we have now for wiki.postgresql.org) by
adding a postgresql authentication backend as well as some experimental
modifications to the
Joshua D. Drake wrote:
On Thu, 10 Apr 2008 10:15:29 -0400
Alvaro Herrera [EMAIL PROTECTED] wrote:
I don't think so because it really isn't a change from what we have
now. There isn't much difference from having a wiki page versus just
having conversations on the patch list and moving
On Thu, 10 Apr 2008 10:28:55 -0400
Alvaro Herrera [EMAIL PROTECTED] wrote:
I admit, I didn't use the wiki page because I got tired of trying to
figure out which page, or list I should be looking at. I was still
get js-kit replies from Bruces pages this week.
I don't know what you're
Am Donnerstag, 10. April 2008 schrieb Tom Lane:
Another is that the email list provides a
push mechanism for putting the proposed patch under the noses of a
bunch of people, a few of whom will hopefully take a sniff ;-).
A tracker is very much more of a pull scenario where someone has to
Alvaro Herrera [EMAIL PROTECTED] writes:
Question for plperl hackers: Should we remove the mention of DBD::PgSPI
from the PL/Perl manual?
It seems like a reasonable suggestion to me, since perl database users
probably already know DBD and don't have to learn something new if they
go that way.
Alvaro Herrera [EMAIL PROTECTED] writes:
So, Greg, after all this feedback, are you going to rework the patch?
I'm a bit busy now but yes, eventually.
I had in mind that it would probably make sense to start over, stealing code
as appropriate. The main thing is that the logic is a bit twisted
On Thu, 10 Apr 2008 07:30:32 -0700
Joshua D. Drake [EMAIL PROTECTED] wrote:
I don't know what you're talking about. There are two wiki pages,
one for the March commitfest and one for May. How can you be
confused on which one are you supposed to look at?
On Thu, 10 Apr 2008 10:45:25 -0400
Tom Lane [EMAIL PROTECTED] wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Question for plperl hackers: Should we remove the mention of
DBD::PgSPI from the PL/Perl manual?
It seems like a reasonable suggestion to me, since perl database users
probably
On Thu, Apr 10, 2008 at 04:12:56PM +0200, Magnus Hagander wrote:
my $replace_re =
qr{^([^:\n\$]+\.c)\s*:\s*(?:%\s*: )?\$(\([^\)]+\))\/(.*)\/[^\/]+$};
Perhaps you would like to comment it using the x format, so that it
doesn't just look like white noise.
That would be a good
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Donnerstag, 10. April 2008 schrieb Tom Lane:
Another is that the email list provides a
push mechanism for putting the proposed patch under the noses of a
bunch of people, a few of whom will hopefully take a sniff ;-).
A tracker is very much more
Joshua D. Drake wrote:
On Thu, 10 Apr 2008 10:45:25 -0400
Tom Lane [EMAIL PROTECTED] wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Question for plperl hackers: Should we remove the mention of
DBD::PgSPI from the PL/Perl manual?
It seems like a reasonable suggestion to me,
Andrew Chernow [EMAIL PROTECTED] writes:
How would the caller of getvalues know whether the error was generated by a
libpqtypes API call or by a libpq API call (like PQgetvalue)? PQgetf should
behave exactely as PQgetvalue does, in regards to errors.
Hm. Well I was thinking of errors from
Joshua D. Drake [EMAIL PROTECTED] writes:
From what I can see on CPAN (unless I am missing something) DBD::PgSPI
hasn't been updated since 2004 and is at version 0.2.
Oh, if it's not a live project then that changes things entirely.
+1 for just dropping the mention.
Greg Smith wrote:
Apache also pushes everything through bugzilla:
http://httpd.apache.org/dev/patches.html
The interesting quote there is:
Traditionally, patches have been submitted on the developer's mailing
list as well as through the bug database. Unfortunately, this has made it
* Bruce Momjian [EMAIL PROTECTED] [080410 11:06]:
I assume you also read this Apache heading:
What if my patch gets ignored?
Because Apache has only a small number of volunteer developers,
and these developers are often very busy, it is possible that your
patch
On Thu, Apr 10, 2008 at 10:56 AM, Gregory Stark [EMAIL PROTECTED] wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
How would the caller of getvalues know whether the error was generated by a
libpqtypes API call or by a libpq API call (like PQgetvalue)? PQgetf should
behave exactely as
Warning - my development views and experiences are highly e-mail
dependant (i.e. linux-kernel style dependant). So if you don't like
email, you probably shouldn't read my response below.
* Joshua D. Drake [EMAIL PROTECTED] [080410 10:48]:
I click the patch for EXPLAIN progress info:
Andrew Chernow wrote:
/* Only for results returned by PQresultDup. This
* will append a new tuple to res. A PGresAttValue
* is allocated and put at index 'res-ntups'. This
* is similar to pqAddTuple except that the tuples
* table has been pre-allocated. In our case, ntups
* and
Brendan Jurd wrote:
Another is that the email list provides a
push mechanism for putting the proposed patch under the noses of a
bunch of people, a few of whom will hopefully take a sniff ;-).
A tracker is very much more of a pull scenario where someone has to
actively go looking for
Joshua D. Drake [EMAIL PROTECTED] writes:
But now what?
If you've got substantive comments to make, you make them by replying to
the original email, same as it ever was. The wiki page is an index of
email threads that need attention.
Small comments can just be left on the wiki page, but that's
Stefan Kaltenbrunner wrote:
Gregory Stark wrote:
Brendan Jurd [EMAIL PROTECTED] writes:
The typical way to solve this is to have the tracker send an automatic
notification email to a list saying Hey, there's a new ticket at ,
come and check it out.
Unfortunately that is the
* GIT (Grouped Index Tuple) indexes, which achieve index space savings
in btrees by having a single index tuple represent multiple heap
tuples
(on a single heap page) containing a range of key values. I am not
sure
what the development status is --- Heikki had submitted a completed
patch
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Donnerstag, 10. April 2008 schrieb Tom Dunstan:
Even so I reckon
that would create vastly more noise than signal in the eventual
tracker - part of the existing problem has been that wading through
list archives is a pain for someone wanting to
Dimitri Fontaine [EMAIL PROTECTED] writes:
It turned around the error was related to the definition of my gpr_penalty()
function, which I wanted to expose as the GiST internal and a SQL callable
one too (for debugging and tests purpose). I forgot to define the internal
one in the prefix.c
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
From what I can see on CPAN (unless I am missing something) DBD::PgSPI
hasn't been updated since 2004 and is at version 0.2.
Oh, if it's not a live project then that changes things entirely.
+1 for just dropping the mention.
Done.
Joshua D. Drake [EMAIL PROTECTED] writes:
Am I supposed to look at the wiki page or bruce pages, or am I supposed
to replying on the list about something. All of which happen during
this fest.
We were maintaining status on both pages for this fest, as an experiment
to see which was more
On Thu, 10 Apr 2008 11:15:08 -0400
Aidan Van Dyk [EMAIL PROTECTED] wrote:
* Where do I comment?
In your mail program.
To where? Development discussion is supposed to happen on -hackers but
a patch is likely on -patches. Although we are allowed to discuss on
-patches as long as it is
On Thu, 10 Apr 2008 11:17:37 -0400
Tom Lane [EMAIL PROTECTED] wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
But now what?
If you've got substantive comments to make, you make them by replying
to the original email, same as it ever was. The wiki page is an
index of email threads that
Le jeudi 10 avril 2008, Gregory Stark a écrit :
I'm getting interested now. How was __pr_penalty defined? What was the
declaration you were missing in prefix.c?
In fact __pr_penalty is the internal code called from both the SQL callable
functions (and some other calling sites). The problem was
Joshua D. Drake wrote:
And in looking at this further, if I look at the Column Level
privelages patch on the wiki, the archive page goes to a -hackers email.
http://archives.postgresql.org/pgsql-hackers/2008-04/msg00049.php
* Do I now respond to the hackers list?
Note that we expect
Aidan Van Dyk wrote:
Lastly, how is this sustainable? I don't see anything that is reducing
Bruce's workload. (for example)
The only think that will ever reduce Bruce's workload is him trusting
that things aren't getting overlooked. The value to the work Bruce does
is that he really
Zeugswetter Andreas OSB SD [EMAIL PROTECTED] writes:
... The really serious problem I've got with it is that
it'd foreclose the possibility of returning actual index keys from btree
indexes, thus basically killing the usefulness of that idea. I'm not
convinced it would offer enough gain to be
Bruce Momjian wrote:
Also, let me add the wiki does not have items that need
discussion/feedback for this commit-fest. Is that going to be added
someday?
Sure, we can create a new section titled items needing discussion.
--
Alvaro Herrera
* Joshua D. Drake [EMAIL PROTECTED] [080410 11:35]:
I now need to open my mail client (fair enough, with me it is alt-tab),
go to my projects-postgresql folder, put a search string in the search
field, find the correct email, reply to the email with my comments, and
possibly an updated patch
On Thu, 10 Apr 2008 11:41:51 -0400
Alvaro Herrera [EMAIL PROTECTED] wrote:
Joshua D. Drake wrote:
And in looking at this further, if I look at the Column Level
privelages patch on the wiki, the archive page goes to a -hackers
email.
Bruce Momjian wrote:
Also, let me add the wiki does not have items that need
discussion/feedback for this commit-fest. Is that going to be added
someday?
I take that back. The March wiki has two items that are clearly not
ready to be applied but need discussion that is happening:
On Thu, 10 Apr 2008 11:53:09 -0400
Aidan Van Dyk [EMAIL PROTECTED] wrote:
I can grab the messageid (or mhonorc url, I've got tools to get the
message id out if it), directly open the message in my reader of
choice, and have the patch, all the discussion threaded nicely, so I
My mail reader
Joshua D. Drake wrote:
On Thu, 10 Apr 2008 11:17:37 -0400
Tom Lane [EMAIL PROTECTED] wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
But now what?
If you've got substantive comments to make, you make them by replying
to the original email, same as it ever was. The wiki page is an
Joshua D. Drake [EMAIL PROTECTED] writes:
Or :)
I can open a web browser, go to tracker.postgresql.org,
review the list of open patches, click one, download, review, comment,
upload new patch if required, done.
And then no one sees your revised patch (except someone watching the
tracker like
Joshua D. Drake [EMAIL PROTECTED] writes:
The message comes up.
Granted... very, very cool that this is all linked, so +1.
But now what?
Now you return, suitably enlightened, to your regularly scheduled life talking
about code (or trackers) on pgsql-hackers and other mailing lists.
--
Alvaro Herrera [EMAIL PROTECTED] writes:
(I wonder what should happen if a message is posted to more than one
list.)
That's a good question. I suppose there are actually multiple archive
entries in that case --- which one is the message-id link taking me to?
I guess whichever list appears
Joshua D. Drake wrote:
The base requirements for this process must be so simple, so easy, that
even if the person has never seen a C patch in his/her life they
understand what is trying to be achieved.
I'm pretty sure we don't want a person who has never seen a C patch in
his life anywhere
On Thu, 10 Apr 2008 12:07:43 -0400
Tom Lane [EMAIL PROTECTED] wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Or :)
I can open a web browser, go to tracker.postgresql.org,
review the list of open patches, click one, download, review,
comment, upload new patch if required, done.
And
Andrew Chernow [EMAIL PROTECTED] writes:
Recap: PQresultDup, PQresultSetFieldDesc and PQresultSetFieldValue.
We feel this approach, which we initially thought wouldn't work, is
better than making pg_result public.
That doesn't seem to me to fit very well with libpq's internals ---
in
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
(I wonder what should happen if a message is posted to more than one
list.)
That's a good question. I suppose there are actually multiple archive
entries in that case --- which one is the message-id link taking me to?
The one on
* Joshua D. Drake [EMAIL PROTECTED] [080410 11:55]:
On Thu, 10 Apr 2008 11:53:09 -0400
Aidan Van Dyk [EMAIL PROTECTED] wrote:
I can grab the messageid (or mhonorc url, I've got tools to get the
message id out if it), directly open the message in my reader of
choice, and have the patch,
* Joshua D. Drake [EMAIL PROTECTED] [080410 10:24]:
Someone, anyone should be able to look exactly one place for the
information required to process a patch.
That one place is (and I think always should be, but I'm biased) going
to be the mailling list.
* Joshua D. Drake [EMAIL PROTECTED] [080410 11:30]:
On Thu, 10 Apr 2008 11:15:08 -0400
Aidan Van Dyk [EMAIL PROTECTED] wrote:
* Where do I comment?
In your mail program.
To where? Development discussion is supposed to happen on -hackers but
a patch is likely on -patches.
Andrew Chernow [EMAIL PROTECTED] writes:
Gregory Stark wrote:
Surely you would just provide a function to get pqtypes errors separate from
libpq errors?
That's extremely akward. Consider the below.
I'm just as suspicious of this as Greg is. In particular, I really
disagree with PQgetf
Gregory Stark [EMAIL PROTECTED] writes:
Csaba Nagy [EMAIL PROTECTED] writes:
For interactive use in the above mentioned scenario you can use the
'screen' command and start as many psqls as needed
Sure, or you could just start multiple xterms or emacs shell buffers
(my preferred setup).
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
Recap: PQresultDup, PQresultSetFieldDesc and PQresultSetFieldValue.
We feel this approach, which we initially thought wouldn't work, is
better than making pg_result public.
That doesn't seem to me to fit very well with libpq's
On Thu, Apr 10, 2008 at 5:27 AM, Ashish Sharma [EMAIL PROTECTED] wrote:
Thanks for the response. Below are the details:
What queries are you running?
We are running normal SQLs and DMLs. Even simple queries like select *
from... are showing the described behavior.
What version
Teodor Sigaev [EMAIL PROTECTED] writes:
* Proposed change to let both amgetnext and amgetmulti mark returned
tuples as candidate matches, that is in need of rechecking of quals
...
indexes). There seemed to be some possible marginal use for it in GIST
indexes, but I'm not convinced that's a
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
A bigger issue is whether this is worth applying when nobody seems to be
working on either of the main uses for it (bitmap indexes and GIT
indexes). There seemed to be some possible marginal use for it in GIST
indexes, but I'm not
1 - 100 of 154 matches
Mail list logo
