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
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
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
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
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
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 ...
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 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
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
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
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
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
[what should happen if a smart shutdown request is received during online
backup mode?
I'll cc: the hackers list, maybe others have something to say to this]
Heikki Linnakangas wrote:
Albe Laurenz wrote:
Moreover, if Shutdown == SmartShutdown, new connections won't be accepted,
and nobody
Andrew Dunstan wrote:
Tom Lane 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 there?
I know there has been lots of versions and technical feedback related to
this proposed feature. However, I have talked to Tom and neither of us
see sufficient user request for this capability to add this code into
the core server. I recommend you place it on pgfoundry and see if you
can get a
Bruce Momjian wrote:
I know there has been lots of versions and technical feedback related to
this proposed feature. However, I have talked to Tom and neither of us
see sufficient user request for this capability to add this code into
the core server. I recommend you place it on pgfoundry
Andrew Dunstan wrote:
Bruce Momjian wrote:
I know there has been lots of versions and technical feedback related to
this proposed feature. However, I have talked to Tom and neither of us
see sufficient user request for this capability to add this code into
the core server. I
Andrew Dunstan [EMAIL PROTECTED] writes:
I think you should conduct a wider survey before you make that decision.
In particular, I'd like to hear from driver writers like Greg Sabino
Mullane and Jeff Davis, as well as regular libpq users.
Well, the survey's already been taken, pretty much:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
I think you should conduct a wider survey before you make that decision.
In particular, I'd like to hear from driver writers like Greg Sabino
Mullane and Jeff Davis, as well as regular libpq users.
I can state that there would be almost
On Tue, Apr 8, 2008 at 12:59 PM, Bruce Momjian [EMAIL PROTECTED] wrote:
Sorry for the bad news. I think we all hoped that enough interest would
be generated for this to be accepted.
I think that's really unfortunate. Personally, I think that anyone
who did any amount of C coding against
On Tue, Apr 8, 2008 at 1:51 PM, Greg Sabino Mullane [EMAIL PROTECTED] wrote:
I think you should conduct a wider survey before you make that decision.
In particular, I'd like to hear from driver writers like Greg Sabino
Mullane and Jeff Davis, as well as regular libpq users.
I can state
Merlin Moncure escribió:
I attributed the silence to general lack of interest and anticipated
this response. However I think that those involved should step back
and take a look at what they are walking away from here.
I suggest you take a survey on a more widely read forum, like
Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
I think you should conduct a wider survey before you make that decision.
In particular, I'd like to hear from driver writers like Greg Sabino
Mullane and Jeff Davis, as well as regular libpq users.
I can state
Merlin Moncure [EMAIL PROTECTED] writes:
On Tue, Apr 8, 2008 at 1:51 PM, Greg Sabino Mullane [EMAIL PROTECTED] wrote:
I can state that there would be almost zero chance this would ever be
used by DBD::Pg, as it would seem to add overhead with no additional
functionality over what we already
On Tue, 08 Apr 2008 14:34:51 -0400
Andrew Chernow [EMAIL PROTECTED] wrote:
I am not sure why Tom is worried about source code size, normally the
concern is linked size. Code comments were never finished, as the
Every byte added is a byte maintained (or not).
Joshua D. Drake
--
The
Tom Lane wrote:
Better support for arrays and composites is certainly something that
people might want, but the problem with this design is that it forces
them to buy into a number of other decisions that they don't necessarily
want.
I could see adding four functions to libpq that create and
On Tue, Apr 8, 2008 at 2:49 PM, Andrew Dunstan [EMAIL PROTECTED] wrote:
Better support for arrays and composites is certainly something that
people might want, but the problem with this design is that it forces
them to buy into a number of other decisions that they don't necessarily
want.
Tom Lane wrote:
Better support for arrays and composites is certainly something that
people might want, but the problem with this design is that it forces
them to buy into a number of other decisions that they don't necessarily
want.
regards, tom lane
What
Joshua D. Drake [EMAIL PROTECTED] writes:
On Tue, 08 Apr 2008 14:34:51 -0400
Andrew Chernow [EMAIL PROTECTED] wrote:
I am not sure why Tom is worried about source code size, normally the
concern is linked size. Code comments were never finished, as the
Every byte added is a byte
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
On Tue, 08 Apr 2008 14:34:51 -0400
Andrew Chernow [EMAIL PROTECTED] wrote:
I am not sure why Tom is worried about source code size, normally the
concern is linked size. Code comments were never finished, as the
Every byte
Andrew Chernow [EMAIL PROTECTED] writes:
Tom Lane wrote:
Better support for arrays and composites is certainly something that
people might want, but the problem with this design is that it forces
them to buy into a number of other decisions that they don't necessarily
want.
What decisions
On Tue, Apr 8, 2008 at 3:10 PM, Bruce Momjian [EMAIL PROTECTED] wrote:
Actually I was thinking more about disk footprint. Andrew's comment is
correct if you work with statically linked code where the compiler pulls
out only the needed .o files from a .a library, but that's pretty out of
Merlin Moncure wrote:
I attributed the silence to general lack of interest and anticipated
this response. However I think that those involved should step back
and take a look at what they are walking away from here.
Agreed. There are technical issues, but they can be addressed with
work. The
On Tue, Apr 8, 2008 at 3:22 PM, Tom Lane [EMAIL PROTECTED] wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
Tom Lane wrote:
Better support for arrays and composites is certainly something that
people might want, but the problem with this design is that it forces
them to buy into a
On Tue, Apr 08, 2008 at 02:34:51PM -0400, Andrew Chernow wrote:
This idea is for the libpq user, although driver writers could find it
handy as well. Really, anyone who uses libpq directly. That's the real
audience.
Quite, I'm writing array parsing code right now and this would make my
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
On Tue, Apr 08, 2008 at 02:34:51PM -0400, Andrew Chernow wrote:
This idea is for the libpq user, although driver writers could find it
handy as well. Really, anyone who uses libpq directly. That's the real
audience.
Quite,
Martijn van Oosterhout wrote:
How tight is the link to libpq? Could it exist as a seperate library:
libpqbin or something? Still in core, just only used by the people who
want it.
I gave this a lot of thought and I do think we could abstract this. The
idea is to complie it in or out.
Add
Andrew Chernow wrote:
Martijn van Oosterhout wrote:
How tight is the link to libpq? Could it exist as a seperate library:
libpqbin or something? Still in core, just only used by the people who
want it.
I gave this a lot of thought and I do think we could abstract this. The
idea is to
Merlin Moncure [EMAIL PROTECTED] writes:
Actually I was thinking more about disk footprint. Andrew's comment is
correct if you work with statically linked code where the compiler pulls
out only the needed .o files from a .a library, but that's pretty out of
fashion these days. Most people
Andrew Chernow [EMAIL PROTECTED] writes:
I gave this a lot of thought and I do think we could abstract this. The
idea is to complie it in or out.
[shrug...] So the packagers will compile it out, and you're still hosed,
or at least any users who'd like to use it are.
Forgot to say: There is
Bruce Momjian wrote:
Martijn van Oosterhout wrote:
How tight is the link to libpq? Could it exist as a seperate library:
libpqbin or something? Still in core, just only used by the people who
want it.
The idea of pgfoundry was that it would be an independent library and
could be used
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
I gave this a lot of thought and I do think we could abstract this. The
idea is to complie it in or out.
[shrug...] So the packagers will compile it out, and you're still hosed,
or at least any users who'd like to use it are.
Forgot
Andrew Chernow wrote:
Forgot to say: There is stuff in PGconn, PGresult, PQclear, PQfinish
(maybe a couple other places).
Maybe there's a way we can have libpqtypes adding calls into some
hypothetical libpq hooks. So libpqtypes registers its hooks in _init()
or some such, and it gets picked
Alvaro Herrera wrote:
Andrew Chernow wrote:
Forgot to say: There is stuff in PGconn, PGresult, PQclear, PQfinish
(maybe a couple other places).
Maybe there's a way we can have libpqtypes adding calls into some
hypothetical libpq hooks. So libpqtypes registers its hooks in _init()
or some
Andrew Chernow wrote:
Alvaro Herrera wrote:
Andrew Chernow wrote:
Forgot to say: There is stuff in PGconn, PGresult, PQclear,
PQfinish (maybe a couple other places).
Maybe there's a way we can have libpqtypes adding calls into some
hypothetical libpq hooks. So libpqtypes registers its
Andrew Dunstan wrote:
Please make sure that any scheme you have along these lines will work on
Windows DLLs too.
Ofcourse: LoadLibrary(), GetProcAddress(), __declspec(dllexport).
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list
On Tue, Apr 8, 2008 at 6:09 PM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
Andrew Chernow wrote:
Forgot to say: There is stuff in PGconn, PGresult, PQclear, PQfinish
(maybe a couple other places).
Maybe there's a way we can have libpqtypes adding calls into some
hypothetical libpq hooks.
Alvaro Herrera [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
The idea of pgfoundry was that it would be an independent library and
could be used by people who need it.
I don't think phasing it out to pgfoundry is a good idea, because it has
some dependency on the OIDs of datatypes.
Well,
Andrew Chernow [EMAIL PROTECTED] writes:
Kinda what my last suggestion was. Some tid-bits need to be reside in libpq,
but very little. I was thinking PQtypesEnable(bool) which would dlopen
libpqtypes and map all functions needed. This would leave the function
bodies
of PQputf, PQgetf,
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
Kinda what my last suggestion was. Some tid-bits need to be reside in libpq,
but very little. I was thinking PQtypesEnable(bool) which would dlopen
libpqtypes and map all functions needed. This would leave the function bodies
of
Tom Lane wrote:
This is still 100% backwards. My idea of a libpq hook is something that
could be used by libpgtypes *and other things*. What you are proposing
is something where the entire API of the supposed add-on is hard-wired
into libpq. That's just bad design, especially when the
Andrew Chernow wrote:
My idea was not a response to your hook idea. It was different
altogether.
My idea is trying to create one interface where some parts need to be
enabled (nothing wrong with that design, this is a plugin-like model).
Your idea creates two interfaces where one of
Andrew Chernow wrote:
When I say I'd accept some hooks into libpq, I mean some hooks that
could be used by either libpgtypes or something that would like to do
something roughly similar but with a different API offered to clients.
The particular hook that you seem to mostly need is the ability
Andrew Chernow wrote:
Andrew Chernow wrote:
When I say I'd accept some hooks into libpq, I mean some hooks that
could be used by either libpgtypes or something that would like to do
something roughly similar but with a different API offered to clients.
The particular hook that you seem to
Andrew Chernow wrote:
Your method would work as well. The only issue is you still have the
same issue of binary distributed libpqs. Would redhat distribute a
binary linked with libpqtypes? If not, you have the same issue of the
end-user having to compile libpq ... passing -lpqtypes to
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Andrew states:
What about user-defined type registration, sub-classing user or built-in
type handlers, handling of all data types in binary. There is a lot
of new functionality added by this patch to the existing libpq.
All of which may be
Bruce Momjian wrote:
I don't see requiring users to add -lpqtypes to use these functions as a
problem. The idea is that the default libpq would have enough hooks
that you could use it without modification.
You are correct, brain fart on my part. Not sure where my mind was at
but I
I think a wise thing would be for the patch submitters to give a _basic_
outline of what PQparam is trying to accomplish --- I mean like 10-20
lines with a code snippet, or code snippet with/withouth PQparam.
I found this posting from August, 2007 but
it isn't short/clear enough:
That is
On Tue, 2008-04-08 at 13:08 -0400, Andrew Dunstan wrote:
I think you should conduct a wider survey before you make that decision.
In particular, I'd like to hear from driver writers like Greg Sabino
Mullane and Jeff Davis, as well as regular libpq users.
I looked into this today.
*
This patch has an identity crisis. We initially called it PGparam (possibly
mispelled several times as PQparam) and then changed it to libpq type system
(typesys).
Several on patches started to call it libpqtypes, even I did. Any objections to
fixing the name to libpqtypes?
Any thoughts
On Tue, 2008-04-08 at 12:59 -0400, Bruce Momjian wrote:
If you need something exposed by
libpq that is not there already, please let us know.
The things that I found missing in libpq so far are:
* The ability to choose some result columns to be binary-formatted and
others to be
On Tue, Apr 8, 2008 at 8:06 PM, Bruce Momjian [EMAIL PROTECTED] wrote:
I think a wise thing would be for the patch submitters to give a _basic_
outline of what PQparam is trying to accomplish --- I mean like 10-20
lines with a code snippet, or code snippet with/withouth PQparam. Right
now
On Tue, Apr 8, 2008 at 9:28 PM, Jeff Davis [EMAIL PROTECTED] wrote:
with proposed changes, (I think) all your suggestions are addressed/moot. see:
* The ability to choose some result columns to be binary-formatted and
others to be text-formatted. I haven't thought of a reasonable API for
On Tue, 2008-04-08 at 15:22 -0400, Tom Lane wrote:
Well, for starters, using binary format. It is undeniable that that
creates more portability risks (cross-architecture and cross-PG-version
issues) than text format. Not everyone wants to take those risks for
benefits that may not be
Jeff Davis wrote:
On Tue, 2008-04-08 at 15:22 -0400, Tom Lane wrote:
Well, for starters, using binary format. It is undeniable that that
creates more portability risks (cross-architecture and cross-PG-version
issues) than text format. Not everyone wants to take those risks for
benefits that
On Tue, Apr 8, 2008 at 9:21 PM, Jeff Davis [EMAIL PROTECTED] wrote:
I looked into this today.
* Arrays and composites
Better ability in libpq to parse and construct arrays and composites
would be helpful. I think this is worthwhile to consider, and I would
expose the functionality (at
Jeff Davis [EMAIL PROTECTED] writes:
On Tue, 2008-04-08 at 15:22 -0400, Tom Lane wrote:
Well, for starters, using binary format. It is undeniable that that
creates more portability risks (cross-architecture and cross-PG-version
issues) than text format. Not everyone wants to take those risks
On Tue, Apr 8, 2008 at 10:15 PM, Tom Lane [EMAIL PROTECTED] wrote:
The biggie is floating-point format. IEEE standard is not quite
universal ... and even for platforms that fully adhere to that standard,
it's not entirely clear that we get the endianness issues correct.
There used to be
Andrew Chernow wrote:
Any thoughts on the hooking suggested by Tom? It sounds like it should
be generic enough so more than just libpqtypes can make use of it. I
think something of this nature should have input before I do anything.
Possible Hook points: (at least ones needed by
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.
Below is a raw shell of an idea that will work for libpqtypes.
On Tue, 2008-04-08 at 22:15 -0400, Tom Lane wrote:
The biggie is floating-point format. IEEE standard is not quite
universal ... and even for platforms that fully adhere to that standard,
it's not entirely clear that we get the endianness issues correct.
There used to be platforms where FP
On Tue, 2008-04-08 at 22:06 -0400, Merlin Moncure wrote:
This is a valid concern. That said, the in/out functions don't change
_that_ much, and even if they did..there are solutions to this
problem. Forwards compatibility is the worst case (8.4 libpq
connecting to 8.5 server). If this
There are many cases that are fairly hard to get a perfect mapping. If
you use PGtime, for instance, there are no C operators for it
Yeah, our patch is designed to allow one to interface with libpq using C data
types, rather than strings (most common) or for the brave external binary
On Sun, Apr 06, 2008 at 11:29:50PM +0100, Gregory Stark wrote:
I wonder if there's much of a use case for any statements aside from
CREATE statements.
Yes. Some modules could have COPY or equivalent in them, as they
could easily contain data.
Cheers,
David.
--
David Fetter [EMAIL PROTECTED]
Tom Lane 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 there?
I have changed the
On Sun, Mar 30, 2008 at 3:09 PM, Tom Lane [EMAIL PROTECTED] wrote:
I looked this over and realized that it has little to do with the
functionality that was so painfully hashed out in the original
discussion thread here:
http://archives.postgresql.org/pgsql-hackers/2006-12/msg00207.php
As
Based on recent patch feedback from Tom, this has been saved for the
next commit-fest:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Tom Lane wrote:
Sibte Abbas [EMAIL PROTECTED] writes:
On 9/9/07,
Am Samstag, den 29.03.2008, 12:25 + schrieb [EMAIL PROTECTED]:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Feb 23, 2008 at 01:13:38PM +0100, Mathias Hasselmann wrote:
[...]
Avahi/Bonjour/DNS-SD support[1] is very important, for integrating
Postgresql with modern
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Apr 01, 2008 at 09:35:56AM +0200, Mathias Hasselmann wrote:
Am Samstag, den 29.03.2008, 12:25 + schrieb [EMAIL PROTECTED]:
[...]
Sorry for a dumb question, but I couldn't figure that out from your
references [1]..[4]: does that mean
Am Dienstag, den 01.04.2008, 12:02 + schrieb [EMAIL PROTECTED]:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Apr 01, 2008 at 09:35:56AM +0200, Mathias Hasselmann wrote:
Am Samstag, den 29.03.2008, 12:25 + schrieb [EMAIL PROTECTED]:
[...]
Sorry for a dumb question, but
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Apr 01, 2008 at 05:07:31PM +0200, Mathias Hasselmann wrote:
[...]
Personally, I'be rather scared than delighted ;-)
So in data centers you don't even trust the machines in your broadcast
domain?
Kind of. Put it another way: never have
On Tue, 2008-04-01 at 15:34 +, [EMAIL PROTECTED] wrote:
I would really prefer a more loosely coupled system.
The functionality will be much the same. The implementation would be
more difficult and obscure and there would be more points of failure and
more things to configure, but it wouldn't
Hi Alex,
On Sun, Mar 30, 2008 at 7:10 AM, Alex Hunsaker [EMAIL PROTECTED] wrote:
(trimmed cc's)
Find attached inherited_constraint_v2.patch
Changes since v1:
-rebased against latest HEAD
-changed enum { Anum_pg_constraint_... } back into #define
Anum_pg_constraint_...
-remove whitespace
Am Donnerstag, 6. März 2008 schrieb Tom Lane:
What I propose doing about this is a small variant on Peter's original
suggestion: compute the estimated selectivity for
col = 'prefix'
and clamp the result of prefix_selectivity to be at least that.
OK, first results with this patch are
Peter Eisentraut [EMAIL PROTECTED] writes:
OK, first results with this patch are in: The selectivity estimations are
adjusted nicely, but the cost calculation doesn't change at all. Before:
I've forgotten the context ... what's the whole query and plan again?
And which PG version exactly?
Am Montag, 31. März 2008 schrieb Tom Lane:
Peter Eisentraut [EMAIL PROTECTED] writes:
OK, first results with this patch are in: The selectivity estimations are
adjusted nicely, but the cost calculation doesn't change at all. Before:
I've forgotten the context ... what's the whole query and
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Montag, 31. März 2008 schrieb Tom Lane:
I've forgotten the context ... what's the whole query and plan again?
And which PG version exactly?
Please see http://archives.postgresql.org/pgsql-hackers/2008-01/msg00048.php
Hm. Now that I think about
On Mon, Mar 31, 2008 at 2:36 AM, NikhilS [EMAIL PROTECTED] wrote:
Hi Alex,
I was taking a look at this patch to add the pg_dump related changes. Just
wanted to give you a heads up as this patch crashes if we run make
installcheck. Seems there is an issue introduced in the CREATE TABLE
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 there?
regards, tom lane
--
Sent via
Sibte Abbas [EMAIL PROTECTED] writes:
On 9/9/07, Sibte Abbas [EMAIL PROTECTED] wrote:
Attached is the patch for the TODO item mentioned at
http://archives.postgresql.org/pgsql-hackers/2007-09/msg00352.php
I looked this over and realized that it has little to do with the
functionality that was
Bruce Momjian wrote:
Alvaro Herrera wrote:
Tomas Doran wrote:
On 28 Mar 2008, at 17:23, Bruce Momjian wrote:
Perhaps we could name it received_query() to indicate it is what the
backend received and it not necessarily the _current_ query.
reveived_query() sounds like a very
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Feb 23, 2008 at 01:13:38PM +0100, Mathias Hasselmann wrote:
[...]
Avahi/Bonjour/DNS-SD support[1] is very important, for integrating
Postgresql with modern desktop environments like OSX, GNOME, KDE: It's
very convenient to choose active
Bruce Momjian [EMAIL PROTECTED] writes:
Uh, I think based on other usage it should be called client_statement().
That is *exactly* the wrong thing, because statement specifically
means one SQL statement.
client_query seems about the best compromise I've heard so far.
It's too bad we didn't
401 - 500 of 3201 matches
Mail list logo
