[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 nobod
Jonah H. Harris wrote:
On Mon, Apr 7, 2008 at 2:58 PM, Heikki Linnakangas
<[EMAIL PROTECTED]> wrote:
Incidentally, I looked at this stuff just a couple of days ago, and it
occurred to me that we really should make it easier to take a hot backup
with that mechanism. We shouldn't require setting
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Apr 07, 2008 at 03:03:41PM -0400, Jonah H. Harris wrote:
> On Mon, Apr 7, 2008 at 2:58 PM, Heikki Linnakangas
> <[EMAIL PROTECTED]> wrote:
> > Incidentally, I looked at this stuff just a couple of days ago, and it
[...]
> Or checkpoint, yes?
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
> > [EMAIL PROTECTED] (Peter Eisentraut) writes:
> >
> >> Implement a few changes to how shared libraries and dynamically
> >> loadable modules are built.
> >>
> >
> > Seems this patch has broken all the Windows buildfarm animals ... is
> > anyb
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 vol
[EMAIL PROTECTED] wrote:
Checkpoinitng is definitely coolest. If your file system doesn't do
that, rsync is a good poor man's replacement:
first rsync (takes long)
(or work from an older backup)
pg_start_backup(...)
rsync (should be much faster)
rsync WAL
pg_stop_backup()
Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > Just throwing out a crazy idea. What if we had a commitfest as
> > scheduled at the start of May but made it a Tom-free commitfest.
> > Specifically to try to organize a larger work-force rather than to
> > leave it all on Tom's should
Le mardi 08 avril 2008, Tom Lane a écrit :
> Dimitri Fontaine <[EMAIL PROTECTED]> writes:
> > And my main concern would still be left as-is, COPY wouldn't have any
> > facility to cope with data representation not matching what datatype
> > input functions want to read.
>
> That's sufficiently cove
The last thread about Free Space Map evolved into discussion about
whether the FSM and other kinds of auxiliary data should be stored
within the heap pages, in "map forks", or auxiliary relfilenodes
attached to the relation. It seems the consensus was to go with the map
forks, but what I really
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Apr 8, 2008 at 6:33 PM, Heikki Linnakangas wrote:
> For example:
>
> 9
> 4 9
> 2 4 0 9
>
> The leaf nodes correspond the heap pages, so page #0 has 2 units of free
> space, page #1 has 4, page #1 is full and page has 9.
>
> Let
On Tue, Apr 8, 2008 at 9:54 AM, Brendan Jurd <[EMAIL PROTECTED]> wrote:
> If I understand your design correctly, this claim isn't true. If the
> topmost node reports 9 bytes free, could you not have seven pages each
> with 1 byte free, and an eighth page with 2 bytes free?
>
> 9
>
On Tue, 2008-04-08 at 09:33 +0100, Heikki Linnakangas wrote:
> The last thread about Free Space Map evolved into discussion about
> whether the FSM and other kinds of auxiliary data should be stored
> within the heap pages, in "map forks", or auxiliary relfilenodes
> attached to the relation. I
Zoltan Boszormenyi írta:
Decibel! írta:
On Apr 3, 2008, at 12:52 AM, Zoltan Boszormenyi wrote:
Where is the info in the sequence to provide restarting with
the _original_ start value?
There isn't any. If you want the sequence to start at some magic
value, adjust the minimum value.
There's
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
will look something l
On Tue, Apr 8, 2008 at 2:03 PM, Heikki Linnakangas
<[EMAIL PROTECTED]> wrote:
> Our current code doesn't support 2, as we always update the FSM in bulk
> after vacuum, but we will need that capability to be able to do partial
> vacuums in the future.
>
+1 for that. This will be extremely useful
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> For example:
>
> 9
> 4 9
> 2 4 0 9
It occurs to me now that this it actually wouldn't be so easy to ripple up
changes due to the amount amount of space *decreasing*. Consider if you reduce
the leaf 9 to an 8. You want to decrease its p
On Tue, 2008-04-08 at 13:38 +0300, 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 th
Bruce Momjian wrote:
> That private email list has grown into something official because I am
> more thorough about it than most. If the community wants a more
> collaborative tool, they can create one or ask for additions to my web
> pages. If I need to take my pages offline to help, fine.
>
>
"Alvaro Herrera" <[EMAIL PROTECTED]> writes:
> FWIW I've been asking patch submitters (privately) to add the patches
> they submit to the May commitfest pages, and they've mostly done it
> right away. If you click the history link on the May page you can see
> changes from Pavel Stehule, Teodor,
Gregory Stark wrote:
> I would like to suggest a few attributes we want for each patch:
[...]
> My first instinct is to convert it to a table. But perhaps we could just stick
> these attributes in the current format as sublist items under each major
> bullet point.
I agree -- having these attri
Alvaro Herrera wrote:
> > Personally I don't think either the March or May wiki pages are accurate
> > enough, so that isn't a good sign.
>
> To me, what this means is that you're the perfect person to be helping
> making the wiki pages more accurate to cover all items that need
> attention. The
Would it be a lot of trouble to extend the ability that databases have
to store variables (add_missing_from, array_nulls, etc.) to tables and
columns, for use with user-defined variables?
This would make it cleaner, I think, to do things like automatically
build UIs for a table, using the variable
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Apr 08, 2008 at 08:52:03AM +0100, Heikki Linnakangas wrote:
> [EMAIL PROTECTED] wrote:
[...]
> 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,
>
Dimitri Fontaine <[EMAIL PROTECTED]> writes:
> Le mardi 08 avril 2008, Tom Lane a écrit :
>> That's sufficiently covered by the proposal to allow a COPY FROM as a
>> table source within SELECT, no?
> Well, yes, the table source has text as datatypes and the select expression
> on
> the column
"Kev" <[EMAIL PROTECTED]> writes:
> Would it be a lot of trouble to extend the ability that databases have
> to store variables (add_missing_from, array_nulls, etc.) to tables and
> columns, for use with user-defined variables?
Not following what you're trying to say at all. Perhaps an example of
Hi,
So far I've posted two patches on snapshot tracking: one to keep track
of "regular" snapshots[1] and another to keep track of snapshots used as
ActiveSnapshot[2].
[1] http://archives.postgresql.org/message-id/[EMAIL PROTECTED]
[2] http://archives.postgresql.org/message-id/[EMAIL PROTECTED]
T
On Apr 8, 10:40 am, [EMAIL PROTECTED] (Gregory Stark) wrote:
> "Kev" <[EMAIL PROTECTED]> writes:
> > Would it be a lot of trouble to extend the ability that databases have
> > to store variables (add_missing_from, array_nulls, etc.) to tables and
> > columns, for use with user-defined variables?
>
I have moved this to the next commit-fest.
---
Gregory Stark wrote:
>
> There's a suspicious ifdef in pg_standby for WIN32 which smells like a kludge
> added to work around a Windows problem which makes it work but at great
Tom Lane wrote:
Dimitri Fontaine <[EMAIL PROTECTED]> writes:
Le mardi 08 avril 2008, Tom Lane a écrit :
That's sufficiently covered by the proposal to allow a COPY FROM as a
table source within SELECT, no?
Well, yes, the table source has text as datatypes and the select
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> (One of the issues that'd have to be addressed to allow a table source
>> syntax is whether it's sane to allow multiple COPY FROM STDIN in a
>> single query. If so, how does it work; if not, how do we prevent it?)
> I don't see why i
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Could we make each COPY target
behave like an SRF, stashing its data in a tuplestore?
The first question is what is the wire-protocol definition. In
particular, how would the client know what order to send the COPY
datasets
Among the consequences of creating a temp table is the fact that we
create pg_shdepend entries for the owner. This is largely unnecessary
-- we only need it when the table owner is not the authenticated user.
I hereby propose we don't create those entries, since obviously the
tables would go away
Alvaro Herrera wrote:
> Among the consequences of creating a temp table is the fact that we
> create pg_shdepend entries for the owner. This is largely unnecessary
> -- we only need it when the table owner is not the authenticated user.
> I hereby propose we don't create those entries, since obvio
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, individual p
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 it work.
I
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 su
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Among the consequences of creating a temp table is the fact that we
> > create pg_shdepend entries for the owner. This is largely unnecessary
> > -- we only need it when the table owner is not the authenticated user.
> > I hereby propose we don't cr
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Is there a big demand for multiple datasets on the wire in a situation
> like this? How about if we allow multiple COPY targets but at most one
> from STDIN, at least for one go round?
That's exactly what I was saying (or at least trying to imply) as
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
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.
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
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
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
-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
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
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?
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
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" <[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
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
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
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
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
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
>
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
"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:
> "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
>
"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
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
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
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
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
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: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:
> 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
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
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 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
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
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.
>
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
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
[ 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
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
"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.
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
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
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
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
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 picke
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
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
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
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
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 (
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/
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:
> 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.
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
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
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:
> 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
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
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
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:
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
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
1 - 100 of 138 matches
Mail list logo