>> * 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 tup
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-ex
-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
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 l
"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 ar
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 sepa
-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
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 20
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 PostgreS
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
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
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
-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 wh
-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 track
-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 crac
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 tex
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 t
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
E
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 mu
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
-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
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
> chan
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
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
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
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 sa
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 curre
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,
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 whe
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 desi
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
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 volu
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
>
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 unn
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
"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
CStringGetTextDatu
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
c
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 tables/s
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 br
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 mo
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, in
> 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 be
> > 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 = (bo
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 mad
"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 D
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 lis
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
"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,
"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 s
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
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
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 h
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 op
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
> objec
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 PQquoteIde
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 yo
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
>
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 outpu
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
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 strongl
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 i
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 a
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, 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 sa
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
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 ac
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 b
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 cu
* 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
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 s
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 apach
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 perf
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 wa
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
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 s
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
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
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
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 libr
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
ho
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 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 quest
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
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 questio
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 b
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
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 tha
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 fast
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.
>
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,
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
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 behavi
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, altho
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
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 did
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
>
"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".
>
"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 t
"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;
> ...
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 care
100 matches
Mail list logo
