Tom Lane wrote:
This isn't really about tools. It's about who wants to put in the
day-after-day, year-after-year drudge work to maintain the queue.
Whoever wants to do the work can pick their tools...
I still think it would be best if the patch authors did the work. They
are the ones who
Jeff Davis [EMAIL PROTECTED] writes:
* Binary formatting
The exclusive use of binary formats is worrisome to me. This circumvents
one level of indirection that we have (i.e. that everything moves
through in/out functions), and will impose a backwards-compatibility
requirement on the
Tom Lane [EMAIL PROTECTED] writes:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
It strikes me that with these semantics, \cwait is a lot like a thread
join operation, so we could call it \join or \j.
FWIW on POSIX shell there's something similar called wait.
Tom Lane [EMAIL PROTECTED] writes:
I believe the reason the spec is written in the particular way that
it is is that they wanted to allow, e.g.,
set transaction isolation level serializable;
set transaction read only;
sql-command;
sql-command;
...
On Wed, Apr 9, 2008 at 6:13 AM, Gregory Stark [EMAIL PROTECTED] wrote:
The exclusive use of binary formats is worrisome to me. This circumvents
one level of indirection that we have (i.e. that everything moves
through in/out functions), and will impose a backwards-compatibility
Merlin Moncure wrote:
However, due to libpq limitations, if any datatype must
return text the entire result must be text (resultFormat)...this is
also interestingly true for functions that return 'void'. So, at
present, to use PQgetf, you result set must be binary.
I'm surprised you
On Wed, Apr 9, 2008 at 8:04 AM, Andrew Dunstan [EMAIL PROTECTED] wrote:
\ Merlin Moncure wrote:
However, due to libpq limitations, if any datatype must
return text the entire result must be text (resultFormat)...this is
also interestingly true for functions that return 'void'. So, at
Andrew Dunstan wrote:
Merlin Moncure wrote:
However, due to libpq limitations, if any datatype must
return text the entire result must be text (resultFormat)...this is
I'm surprised you didn't try to address that limitation.
That would change the existing behavior of resultFormat,
Andrew Chernow wrote:
Andrew Dunstan wrote:
Merlin Moncure wrote:
However, due to libpq limitations, if any datatype must
return text the entire result must be text (resultFormat)...this is
I'm surprised you didn't try to address that limitation.
That would change the existing
Merlin Moncure wrote:
On Wed, Apr 9, 2008 at 8:04 AM, Andrew Dunstan [EMAIL PROTECTED] wrote:
\ Merlin Moncure wrote:
However, due to libpq limitations, if any datatype must
return text the entire result must be text (resultFormat)...this is
also interestingly true for functions that return
Tom wrote:
So I'm of the opinion that there's no good reason to change either our
code or our docs. The standard-incompatibility is with BEGIN, not
SET TRANSACTION, and it's already documented.
Yes.
PS: the proposed patch is buggy as can be anyway: it applies the
change
even if !doit, and
On Wed, 2008-04-09 at 10:17 +0530, Pavan Deolasee wrote:
On Wed, Apr 9, 2008 at 12:22 AM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
Well, if you add the higher levels, we're no longer talking about O(1), but
O(log n) (for a pretty steep logarithm), just like my proposal.
For
Hi,
The setup in question includes PostGRESQL v8.2.4, Java based web servers and
MS.NET based web servers. Following is the fuzzy situation:
1. Our SQL queries run very fast using PSQL (both, from the server as
well as the client).
2. The Java app also retrieves the results very
On Tue, Apr 08, 2008 at 07:18:31PM -0400, Tom Lane wrote:
sure that there's much potential commonality. The thing that's most
problematic about ecpg is that it wants to offer client-side equivalents
of some server datatype-manipulation functions; and I don't actually see
much of any of that
Andrew Chernow wrote:
Yeah, currently composites and arrays only support binary results in
libpqtypes. This forces any array elementType or any member of a
composite to have a send/recv routine. Using the fallback to text
output approach, this limitation on array elements and composite
Andrew Chernow wrote:
Well, I can get it working with a very small patch. We actually don't
need very much in libpq. Although, making it somehow generic enough
to be useful to other extensions is a bit tricky. Please, suggestions
would be helpful.
Quick question on the hook concept
Andrew Chernow wrote:
Andrew Chernow wrote:
Well, I can get it working with a very small patch. We actually
don't need very much in libpq. Although, making it somehow generic
enough to be useful to other extensions is a bit tricky. Please,
suggestions would be helpful.
Quick
On Wed, 2008-04-09 at 18:33 +0530, Ashish Sharma wrote:
Hi,
The setup in question includes PostGRESQL v8.2.4, Java based web
servers and MS.NET based web servers. Following is the fuzzy
situation:
1. Our SQL queries run very fast using PSQL (both, from the
server as well as the
Andrew Chernow wrote:
Andrew Chernow wrote:
Well, I can get it working with a very small patch. We actually
don't need very much in libpq. Although, making it somehow generic
enough to be useful to other extensions is a bit tricky. Please,
suggestions would be helpful.
Quick
Andrew Chernow wrote:
The core of what I am trying to ask is, there doesn't appear to be an
advantage to separating libpqtypes from libpq in terms of space. If
redhat follows their normal policy of include all (probably to make
their distro as feature rich out-of-the-box as possible),
Andrew Dunstan wrote:
I don't get what you're not seeing about this.
All I am trying to say is, redhat's core packages are normally very
inclusive. Like apache, which includes many/most modules in the core
package.
I am still not convinced there is merit to a separate library. But
Andrew Chernow [EMAIL PROTECTED] writes:
There is no need to pass hookData to the hook function. libpqtypes already
accesses PGconn and PGresult directly so it can just access the hookData
member.
That's a habit you'd really be best advised to stop, if you're going to
be a separate library.
Tom Lane wrote:
Shane Ambler [EMAIL PROTECTED] writes:
When switching to a conn we also need a non-destructive way out if it is
busy.
Uh, why? Why would you switch to a connection at all, if you didn't
want its result?
What if you switch to the wrong connection and it hasn't finished. Do
Heikki Linnakangas wrote:
Tom Lane wrote:
This isn't really about tools. It's about who wants to put in the
day-after-day, year-after-year drudge work to maintain the queue.
Whoever wants to do the work can pick their tools...
I still think it would be best if the patch authors did the
Andrew Chernow wrote:
Andrew Dunstan wrote:
I don't get what you're not seeing about this.
All I am trying to say is, redhat's core packages are normally very
inclusive. Like apache, which includes many/most modules in the core
package.
There are plenty of modules that they don't
Hello,
I don't really know since when those commands are provided by psql, but I
found them recently and was quite annoyed by the output given by both of
them.
Though I find that the \du command's output is quite accurate, I wonder why
\dg gives the same informations ?
I would have expected to
Andrew Dunstan wrote:
All I am trying to say is, redhat's core packages are normally very
inclusive. Like apache, which includes many/most modules in the core
package.
There are plenty of modules that they don't include, e.g. mod_fastcgi.
If you want that you download and build it
Heikki Linnakangas [EMAIL PROTECTED] writes:
I still think it would be best if the patch authors did the work. They
are the ones who care about the patch and want the review, and they're
in the best position to know what the status of a patch is.
Unfortunately, a lot of submitters are way
Tom Lane wrote:
This doesn't seem particularly hard, just a matter of following the
relevant mailing lists (mostly -patches, but various offenders send
patches elsewhere) and adding links to the current wiki page.
That's where I'd love to have Bruce to help.
Bruce has made it perfectly
Bruce Momjian wrote:
I think Andrew Chernow is fundamentally confused about dynamic linking,
which apache has to use because it doesn't know what type of file it has
to handle, with linking, which is bound to the application code.
pgtypes is bound to the application code so it is not like
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
There is no need to pass hookData to the hook function. libpqtypes already
accesses PGconn and PGresult directly so it can just access the hookData member.
That's a habit you'd really be best advised to stop, if you're going to
be a
* Tom Lane [EMAIL PROTECTED] [080409 10:40]:
This doesn't seem particularly hard, just a matter of following the
relevant mailing lists (mostly -patches, but various offenders send
patches elsewhere) and adding links to the current wiki page.
I've often been confused that discussion seem to
Aidan Van Dyk wrote:
-- Start of PGP signed section.
* Tom Lane [EMAIL PROTECTED] [080409 10:40]:
This doesn't seem particularly hard, just a matter of following the
relevant mailing lists (mostly -patches, but various offenders send
patches elsewhere) and adding links to the current
Josh Berkus wrote:
I have seen stupid decisions in the past, but requesting unused
addresses to be used for GSoC registration should certainly win a prize
somewhere.
Well, why did you use that address for your Google account, then?
If Google weren't so opaque about creating Google accounts
Andrew Chernow wrote:
What parts of PGconn/PGresult do you need to touch that aren't exposed
already?
Don't need direct access to PGconn at all.
result:
null_field
tupArrSize
client_encoding (need a PGconn for this which might be dead)
pqSetResultError
pqResultAlloc
pqResultStrdup
Also, we
Alvaro Herrera [EMAIL PROTECTED] writes:
Andrew Chernow wrote:
The core of what I am trying to ask is, there doesn't appear to be an
advantage to separating libpqtypes from libpq in terms of space.
My guess is that if we provide an useful library, Redhat will distribute
it some way or
On Wed, Apr 9, 2008 at 11:17 AM, Andrew Chernow [EMAIL PROTECTED] wrote:
We can read args-get.result properties using PQfuncs with no problem. But
we have no way of assign these values to our result 'r'.
By the way, our decision to 'create the result' when exposing arrays
and composites saved
Tom Lane wrote:
The key phrase in that being some way or another. Red Hat works with
a concept of core vs extras (or another way to look at it being what
comes on the CDs vs what you have to download from someplace). I think
it's highly likely that libpgtypes would end up in extras. If you
On Wed, 9 Apr 2008 11:18:38 -0400
Alvaro Herrera [EMAIL PROTECTED] wrote:
Josh Berkus wrote:
I have seen stupid decisions in the past, but requesting unused
addresses to be used for GSoC registration should certainly win a
prize somewhere.
Well, why did you use that address for your
Shane Ambler wrote:
Think jobs in a shell, you can suspend a long running process then send
it to the background to work and go on with something else.
So I am thinking something like C-z that will allow you to switch out of
a task that is waiting for results without having to stop it
Andrew Chernow [EMAIL PROTECTED] writes:
If you are suggesting that libpqtypes should not access internal libpq,
than this idea won't work. We can pull all the code out and hook in, as
you suggested, but we had no plans of abstracting from internal libpq.
That's exactly what I'm strongly
David BOURIAUD wrote:
Hello,
I don't really know since when those commands are provided by psql, but I
found them recently and was quite annoyed by the output given by both of
them.
Not certain since when but I would think from a very early version.
Though I find that the \du command's
On Wed, Apr 9, 2008 at 10:56 AM, Hannu Krosing [EMAIL PROTECTED] wrote:
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:
Aidan Van Dyk [EMAIL PROTECTED] writes:
I've often been confused that discussion seem to seamlessly be on either
-patches, or -hackers. From the understanding I got on the mailing
list pages (http://archives.postgresql.org/), it seems like -patches is
supposed to be only for patches, and
On Tue, 2008-04-08 at 21:49 -0400, Merlin Moncure wrote:
* an escapeIdent function.
not sure what this is...
Similar to the quote_ident() function in postgresql:
= select quote_ident('foo');
quote_ident
-
foo
(1 row)
It could be called something like PQquoteIdent or
Tom Lane wrote:
That's exactly what I'm strongly suggesting. If you need to include
libpq-int.h at all, then your library will be forever fragile, and could
very well end up classified as don't ship this at all, it's too likely
to break.
regards, tom lane
I see
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.
Also, we basically need write access to every member inside a result
object ...
Greetings,
I'm having a problem using heap_form_tuple. I'm trying to form a HeapTuple to
use it later with simple_heap_insert. My code looks like this:
--
Datum *values;
bool *nulls;
int natts;
TupleDesc tupDesc;
HeapTuple tuple;
...
tupDesc = RelationGetDescr(...my previously
On Wed, Apr 9, 2008 at 10:48 PM, Claudio Rossi [EMAIL PROTECTED] wrote:
nulls = (bool *)palloc(natts*sizeof(bool *));
May not be related to segfault you are seeing, but this looks completely wrong.
You want array of bool and not (bool *).
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB
Alvaro Herrera [EMAIL PROTECTED] writes:
Shane Ambler wrote:
So I am thinking something like C-z that will allow you to switch out of
a task that is waiting for results without having to stop it with C-c.
I agree -- we would need to have a mode on which it is not on any
connection, to
Tom Lane wrote:
Hmm. I guess it wouldn't be completely out of the question to expose
the contents of PGresult as part of libpq's API. We haven't changed it
often, and it's hard to imagine a change that wouldn't be associated
with a major-version change anyhow. We could do some things to make
Tom Lane [EMAIL PROTECTED] writes:
If not, would it be possible to some how force reply-to of pg-patches to
-hackers?
No, we aren't going to do that. It wouldn't work anyway; you can't
force people to send messages to one list rather than another, and
the mail list software is surely not
Bruce Momjian [EMAIL PROTECTED] writes:
I still think it would be best if the patch authors did the work. They
are the ones who care about the patch and want the review, and they're
in the best position to know what the status of a patch is. Others can
do it as well of course, in the
Gregory Stark [EMAIL PROTECTED] writes:
What would move us in the direction of this mythical patch tracker would be
if we knew exactly what our workflow was. Once we know what our workflow is
then we could pick a tool which enforces that workflow.
Well, I don't think we want or need an
Hannu Krosing wrote:
Sabing 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.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list
Claudio Rossi [EMAIL PROTECTED] writes:
values[0] = ...GetDatum(...my datum...);
...
values[natts-1] = ...GetDatum(...my datum...);
You've omitted the details that probably matter. My guess is that
you're inappropriately converting one of these values to a Datum,
or converting it to a Datum
Bruce Momjian wrote:
Tom Lane wrote:
This doesn't seem particularly hard, just a matter of following the
relevant mailing lists (mostly -patches, but various offenders send
patches elsewhere) and adding links to the current wiki page.
That's where I'd love to have Bruce to help.
Bruce has
nulls = (bool *)palloc(natts*sizeof(bool *));
May not be related to segfault you are seeing, but this looks completely
wrong.
You want array of bool and not (bool *).
Yeah, you are right but in the original code it's:
values = (Datum *) palloc(natts * sizeof(Datum));
nulls = (bool *)
You've omitted the details that probably matter. My guess is that
you're inappropriately converting one of these values to a Datum,
or converting it to a Datum that's not really of the type the
tuple descriptor specifies.
regards, tom lane
Mate, you just won a beer :)
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
... what I really wanted to discuss is the data structure needed
for the Free Space Map.
The FSM data structure needs to support two basic operations:
1. Fast lookup of page with = X bytes of free space
2. Update of arbitrary,
On Apr 9, 2008, at 12:27 PM, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Shane Ambler wrote:
So I am thinking something like C-z that will allow you to switch
out of
a task that is waiting for results without having to stop it with
C-c.
I agree -- we would need to have a
Tom Lane wrote:
But I'll agree that cross-version hazards are a much more clear and
present danger. We've already broken binary compatibility at least
once since the current binary-I/O system was instituted (intervals
now have three fields not two) and there are obvious candidates for
future
On Apr 8, 2008, at 5:10 PM, Stephen Denne wrote:
I had an annoying experience with COPY within psql yesterday.
I had a dump of just three tables, which I wanted to investigate. I
tried loading them into an empty database, using psql's \i command.
The table creation failed as dependent
Claudio Rossi [EMAIL PROTECTED] writes:
You guessed it right, I was trying to CStringGetDatum into a text field,
now i solved it with
values[n] = DirectFunctionCall1(textin, CStringGetDatum(...string...));
If you're working in CVS HEAD there's an easier way --- see
CStringGetTextDatum.
Florian Pflug [EMAIL PROTECTED] writes:
But isn't that an argument *for* having support for the binary format in
libpq in a form similar to what this patch offers? Then at least you'd
be safe as long as your libpq-version is = your server version.
Currently, there seems to be no safe way to
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Shane Ambler wrote:
So I am thinking something like C-z that will allow you to switch out of
a task that is waiting for results without having to stop it with C-c.
I agree -- we would need to have a mode on which it is not on any
Andrew Chernow [EMAIL PROTECTED] writes:
Tom Lane wrote:
Hmm. I guess it wouldn't be completely out of the question to expose
the contents of PGresult as part of libpq's API.
How about a proxy header (if such an animal exists).
A separate header might be a good idea to discourage
Gregory Stark [EMAIL PROTECTED] writes:
I suggested eliminating pgsql-patches as a
separate mailing list for people to send mail to.
Instead you could subscribe to a version of pgsql-hackers which automatically
had large attachments removed and replaced with a link to the file on a web
page.
On Sun, Mar 30, 2008 at 6:29 PM, Tom Lane [EMAIL PROTECTED] wrote:
Neil Conway [EMAIL PROTECTED] writes:
Applied to HEAD.
At this point it would probably be a good idea if a couple of buildfarm
machines were to start testing builds with --disable-integer-datetimes
... any volunteers out
On Mon, Mar 31, 2008 at 4:02 PM, Tom Lane [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] writes:
Did you commit a patch already, do you want me to rerun the build?
Yes; no --- looks like it'll run by itself in an hour anyay.
I set up a new box with -DCLOBBER_CACHE_ALWAYS called pigeon so that
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 my design to
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)
This could be useful to implement index-only scans, for count(), or to
quickly skip rows when OFFSET is used, or to use only the index
On Wed, 9 Apr 2008, Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
What would move us in the direction of this mythical patch tracker would be
if we knew exactly what our workflow was. Once we know what our workflow is
then we could pick a tool which enforces that workflow.
Well, I
I just finished looking through the various threads about index AM
changes that Bruce has been holding onto in the commit-fest queue.
There seem to be the following issues:
* Proposed change to have amgetmulti return its results by ORing bits
into a caller-supplied TIDBitmap, rather than the
Greg Smith wrote:
Making sure nothing falls through the cracks is exactly the point of an
enforced workflow. It might be a manual operation, it might be some piece
of software, but ultimately you need a well-defined process where things
move around but don't get dropped. Exactly how said
Heikki Linnakangas wrote:
Bruce Momjian wrote:
Tom Lane wrote:
This doesn't seem particularly hard, just a matter of following the
relevant mailing lists (mostly -patches, but various offenders send
patches elsewhere) and adding links to the current wiki page.
That's where I'd love to
Tom Lane wrote:
Perhaps we could do a partial exposure, where the exported struct
declaration contains public fields and there are some private ones
after that.
I have another idea. It would remove a boat load of members that would need to
be exposed (may remove them all).
Can we
Andrew Chernow wrote:
Tom Lane wrote:
Perhaps we could do a partial exposure, where the exported struct
declaration contains public fields and there are some private ones
after that.
I have another idea. It would remove a boat load of members that would
need to be exposed (may remove
I am glad you have summarized this. The details of exactly what was
being proposed was too complex for me to understand before.
---
Tom Lane wrote:
I just finished looking through the various threads about index AM
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Apr 10, 2008 at 12:33 AM, Bruce Momjian
wrote:
Heikki Linnakangas wrote:
I still think it would be best if the patch authors did the work. They
are the ones who care about the patch and want the review, and they're
in the best
On Wed, 9 Apr 2008 20:50:28 -0400 (EDT)
Bruce Momjian [EMAIL PROTECTED] wrote:
Greg Smith wrote:
Making sure nothing falls through the cracks is exactly the point
of an enforced workflow. It might be a manual operation, it might
be some piece of software, but ultimately you need a
Brendan Jurd wrote:
Does that move us in the direction of the patch tracker? That does
raise the bar for patch submitters, though I would catch any patches
that weren't in the tracker.
I suppose you could say that it would raise the bar, but for what it's
worth I would much
Joshua D. Drake wrote:
And when we did whittle it down to a short list there were still very
few people helping.
Yes and that is a much bigger problem.
I was looking for some more text after that sentence. :-(
--
Bruce Momjian [EMAIL PROTECTED]http://momjian.us
On Wed, 9 Apr 2008 21:38:29 -0400 (EDT)
Bruce Momjian [EMAIL PROTECTED] wrote:
I think there is concern that trivial patches wouldn't be submitted
to a patch tracker, especially by new submitters. Again, I am
willing to track the ones that aren't in the patch tracker, but then
we have two
On Wed, 9 Apr 2008 21:40:25 -0400 (EDT)
Bruce Momjian [EMAIL PROTECTED] wrote:
Joshua D. Drake wrote:
And when we did whittle it down to a short list there were still
very few people helping.
Yes and that is a much bigger problem.
I was looking for some more text after that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Wednesday, April 09, 2008 18:33:30 -0700 Joshua D. Drake
[EMAIL PROTECTED] wrote:
On Wed, 9 Apr 2008 20:50:28 -0400 (EDT)
Bruce Momjian [EMAIL PROTECTED] wrote:
Greg Smith wrote:
Making sure nothing falls through the cracks is exactly
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Apr 10, 2008 at 11:38 AM, Bruce Momjian
wrote:
I think there is concern that trivial patches wouldn't be submitted to a
patch tracker, especially by new submitters. Again, I am willing to
track the ones that aren't in the patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Wednesday, April 09, 2008 21:38:29 -0400 Bruce Momjian [EMAIL
PROTECTED]
wrote:
I think there is concern that trivial patches wouldn't be submitted to a
patch tracker, especially by new submitters.
Can I see a show of hands as to who
Marc G. Fournier wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Wednesday, April 09, 2008 21:38:29 -0400 Bruce Momjian [EMAIL
PROTECTED]
wrote:
I think there is concern that trivial patches wouldn't be submitted to a
patch tracker, especially by new submitters.
On Wed, 09 Apr 2008 22:59:43 -0300
Marc G. Fournier [EMAIL PROTECTED] wrote:
Damn, this is starting to get to be a trend ... but, I can't but
agree 100% with this ... we *can* enforce, and I doubt it will have
much (if any) affect on the # of patches that come in, since ppl want
to see their
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 ...
Just as a note... email can be used
On Thu, 10 Apr 2008 12:02:37 +1000
Brendan Jurd [EMAIL PROTECTED] wrote:
It's not like we'd be asking submitters to draw a chalk circle on
their floor and conduct an arcane ritual. =) It's just a website.
No, but that is essentially what we do now :P.
Joshua D. Drake
--
The PostgreSQL
On Wed, 9 Apr 2008, Marc G. Fournier wrote:
Do other large projects accept patches 'ad hoc' like we do? FreeBSD? Linux?
KDE?
The Linux procedure is documented at
http://www.mjmwired.net/kernel/Documentation/SubmittingPatches
Linux was forced into some structure by the SCO lawsuit circa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Wednesday, April 09, 2008 19:06:30 -0700 Joshua D. Drake
[EMAIL PROTECTED] wrote:
On Wed, 09 Apr 2008 22:59:43 -0300
Marc G. Fournier [EMAIL PROTECTED] wrote:
Damn, this is starting to get to be a trend ... but, I can't but
agree 100%
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
Brendan Jurd [EMAIL PROTECTED] writes:
Personally I don't feel that using a patch tracker or wiki is any more
onerous than using an email list, and it's a whole lot more responsive
There are a couple of differences in my mind. One is that the email
list provides an automatic historical
Tom Lane wrote:
* Proposed change to let both amgetnext and amgetmulti mark returned
tuples as candidate matches, that is in need of rechecking of quals
against the real heap tuple. I had originally objected to this on
the grounds that it would require setup work that doesn't happen now,
but
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Apr 10, 2008 at 3:24 PM, Tom Lane wrote:
Brendan Jurd writes:
Personally I don't feel that using a patch tracker or wiki is any more
onerous than using an email list, and it's a whole lot more responsive
There are a couple of
On Tue, Apr 8, 2008 at 10:03 PM, Jonah H. Harris [EMAIL PROTECTED] wrote:
On Tue, Apr 8, 2008 at 9:04 PM, Tom Lane [EMAIL PROTECTED] wrote:
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
99 matches
Mail list logo
