>>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 for
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 pro
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 Wed, 09 Apr 2008 00:59:03 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> > So you are saying, only one person should do this versus a team of
> > individuals? That doesn't seem sustainable.
>
> Uh, no, I did not say that; and indeed I'd much rather see it done
> by a team. My point was that the
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> 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...
> So you are saying
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 updates, I would still call it O(1) because the number of levels
On Wed, 09 Apr 2008 00:28:35 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > Tom lane said over on the concurrent psql thread:
> >> If we do split them then there is going to be some added effort to
> >> maintain the commit fest queue.
>
> > What exac
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Tom lane said over on the concurrent psql thread:
>> If we do split them then there is going to be some added effort to
>> maintain the commit fest queue.
> What exactly are we talking about here? It sounds to me as if my
> tracman email with modific
Alvaro,
Some of you may have mentored GSoC under e-mail addresses different from
your "main" ones. Please check your google account addresses for copious
e-mail. Thanks!
I have seen stupid decisions in the past, but requesting unused
addresses to be used for GSoC registration should certain
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.
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?
This is a pretty fundamental issue, and insisting that you want that
behavior will mak
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 libpqtypes
Shane Ambler <[EMAIL PROTECTED]> writes:
> +1 on the \g& but I would reverse the syntax -
> \g& conn1 CERATE INDEX...;
No, not good. If the command requires multiple lines then this creates
an action-at-a-distance behavior. Thought experiment: what would you
expect here:
\g& conn1
I have applied the following patch to document the use of continuous
archiving backups to allow non-simultaneous snapshots.
I don't think we want to go any farther to stop WAL recycling during
back backups.
---
Bruce Momjia
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 index as a primary key.
>
> You need to present a more convincing use
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
Tom Lane wrote:
\join connID
Switch to connection connID. If it is busy, wait for
command completion and print the result before offering
a new command prompt.
When switching to a conn we also need a non-destructive way out if it is
busy.
\join (or \join - as p
Tom Lane wrote:
\connect& name [ optional connect params ]
\S name
This would require choosing a name for the default session, maybe "-".
Or you could use "1" if you figured that people really would prefer
numbers as IDs.
+1 with name as a string, when an empty string is passe
Tom lane said over on the concurrent psql thread:
If we do split them then there is going to be some added effort to
maintain the commit fest queue. Bruce has made it pretty clear
that he doesn't want to put in any extra cycles here. So someone
else has to step up to the plate if this is going t
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 tho
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 functiona
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 ma
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 mean
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, 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
>
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 text-formatte
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
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.
* Ar
On Tue, 8 Apr 2008 21:03:49 -0400 (EDT)
Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Let me add that politically-charged discussion is something we have
> avoided for many years, and if it continues to appear it will hurt us
> greatly. Our community will be fragmented and dedication to the
> proje
"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 any effective difference
Bruce Momjian wrote:
> > Why are such politically touchy decisions being taken in an anonymous,
> > unarchived forum like IRC, anyway? Especially when what *was*
> > being publicly discussed was an entirely different change?
> > http://archives.postgresql.org/pgsql-docs/2008-04/msg1.php
> >
>
Josh Berkus wrote:
> Folks,
>
> Some of you may have mentored GSoC under e-mail addresses different from
> your "main" ones. Please check your google account addresses for copious
> e-mail. Thanks!
I have seen stupid decisions in the past, but requesting unused
addresses to be used for GSoC r
Tom Lane wrote:
> [EMAIL PROTECTED] (Bruce Momjian) writes:
> > Remove mention of the Berkeley origins of the alias "Postgres" ---
> > seems unnecessary to mention in the FAQ, per discussion on IRC.
>
> This doesn't seem like an improvement in the least. It makes it
> appear that Postgres is just
[EMAIL PROTECTED] (Bruce Momjian) writes:
> Remove mention of the Berkeley origins of the alias "Postgres" ---
> seems unnecessary to mention in the FAQ, per discussion on IRC.
This doesn't seem like an improvement in the least. It makes it
appear that Postgres is just a randomly chosen abbreviat
>
> 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:
>
Tha
[ back to this patch ]
Simon Riggs <[EMAIL PROTECTED]> writes:
> The SQL:2003 standard definition of SET TRANSACTION differs in major
> ways from PostgreSQL's, which produces some interesting behaviour.
> We currently claim conformance, though this is not accurate.
I'm still of the opinion that
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 scratch
-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
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
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 mos
Folks,
Some of you may have mentored GSoC under e-mail addresses different from
your "main" ones. Please check your google account addresses for copious
e-mail. Thanks!
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
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 t
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
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 ad
Hey all,
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. Unless I
completely missed something, there's no way to do this now without a
bit of catalog hackery.
My implementation idea is as follows:
Proposed Syntax (ba
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 PQp
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, PQ
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.
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 li
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".
> http://www.opengroup.org/onlinepubs/009695399/
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 (
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 ho
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 su
Tom Lane wrote:
> I wrote:
> > What seems possibly more useful is to reintroduce \cwait (or hopefully
> > some better name) and give it the semantics of "wait for a response from
> > any active connection; switch to the first one to respond, printing its
> > name, and print its result".
>
> It str
Tom Lane wrote
> Decibel! <[EMAIL PROTECTED]> writes:
> > When restoring from pg_dump(all), if a problem occurs in a COPY
> > command you're going to get a whole slew of errors, because
> as soon
> > as COPY detects a problem it will throw an error and psql will
> > immediately switch to try
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 picke
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
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
I wrote:
> What seems possibly more useful is to reintroduce \cwait (or hopefully
> some better name) and give it the semantics of "wait for a response from
> any active connection; switch to the first one to respond, printing its
> name, and print its result".
It strikes me that with these semant
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: The
Decibel! <[EMAIL PROTECTED]> writes:
> When restoring from pg_dump(all), if a problem occurs in a COPY
> command you're going to get a whole slew of errors, because as soon
> as COPY detects a problem it will throw an error and psql will
> immediately switch to trying to process the remaining
"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.
On Tue, 2008-04-08 at 15:26 -0500, Decibel! wrote:
> My idea to avoid this situation is to add an option to COPY that
> tells it not to throw an error until it runs out of input data.
An alternative would be to have the client continue reading (and
discarding) COPY input until the end-of-COPY-in
[ redirecting to -hackers since -patches isn't the place for general
discussion of feature specifications ]
Gregory Stark <[EMAIL PROTECTED]> writes:
> So based on the feedback and suggestions here this is the interface I suggest:
> \connect& - to open a new connection keeping the existing one
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 compli
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 a
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.
>
When restoring from pg_dump(all), if a problem occurs in a COPY
command you're going to get a whole slew of errors, because as soon
as COPY detects a problem it will throw an error and psql will
immediately switch to trying to process the remaining data that was
meant for COPY as if it was
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
l
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 =
qr{^([^:\n\$]+\.c)\s*:\s*(?:%\s*: )?\$(\([^\)]+\))\/(.*)\/[^\/]+$}
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
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
What I was complaining/suggesting is that we should make what you did to
actually work, because it's a lot simpler. And as Jonah pointed out,
we'd need to inhibit checkpoints between pg_start_backup() and
pg_stop_backup() to make i
Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > "Tom Lane" <[EMAIL PROTECTED]> writes:
> >> Whether it's a good idea or not is a bit debatable though. I'm
> >> concerned about the WAL partition filling up (--> PANIC),
> >> especially if you forget to pg_stop_backup after getting yo
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 =
qr{^([^:\n\$]+\.c)\s*:\s*(?:%\s*: )?\$(\([^\)]+\))\/(.*)\/[^\/]+$};
matches things properly
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
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> Whether it's a good idea or not is a bit debatable though. I'm
>> concerned about the WAL partition filling up (--> PANIC), especially
>> if you forget to pg_stop_backup after getting your backup.
> We check if
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
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Whether it's a good idea or not is a bit debatable though. I'm
> concerned about the WAL partition filling up (--> PANIC), especially
> if you forget to pg_stop_backup after getting your backup.
We check if pg_start_backup in effect when we an ENOSPC erro
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
>
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. T
"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 by
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 decisions
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
>
Pavan Deolasee wrote:
Can we not use bitmaps to track approximate rather than exact free
space ? For example, we can have 8 or 16 buckets of free space.
A page with 1-32 bytes free, goes into bucket 1, a page with at 33-64 bytes
free, goes into bucket 2 and so on. If you want a page with X bytes
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 p
Hannu Krosing wrote:
On Tue, 2008-04-08 at 12:26 +0300, Hannu Krosing wrote:
Probably we could do without sparse files, if we find an efficient way
to compute the "add order" of leaf and parent pages for above algorithm.
if we always add only the minimal needed set of parents then the order
w
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 Post
"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 w
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 that
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
pgsql-gen
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> I agree with that, but I think your idea of not making the pg_shdepend
> >> entries is a pointless and possibly dangerous micro-optimization.
> >> How much actual speedup would it provide, anyway?
>
> > Speedup?
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
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
-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 z
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I agree with that, but I think your idea of not making the pg_shdepend
>> entries is a pointless and possibly dangerous micro-optimization.
>> How much actual speedup would it provide, anyway?
> Speedup? Not sure -- I'm more worried
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 muc
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > So now my thinking is that we should disallow dropping a connected user.
>
> I agree with that, but I think your idea of not making the pg_shdepend
> entries is a pointless and possibly dangerous micro-optimization.
> How much actual
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> So now my thinking is that we should disallow dropping a connected user.
I agree with that, but I think your idea of not making the pg_shdepend
entries is a pointless and possibly dangerous micro-optimization.
How much actual speedup would it provide, a
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.
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 and
1 - 100 of 138 matches
Mail list logo
