Heikki Linnakangas wrote:
1. call pg_start_backup('foo')
2. tar/etc. the whole data directory, except for pg_xlog
3. tar pg_xlog
4. call pg_stop_backup()
If we just made sure that we don't delete or recycle any WAL files while
the backup is being taken, that would work, right?
When is the
[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
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? I
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
anybody on that?
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?
[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
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 shoulders. Not
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 covered by the
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's work
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
4
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. It
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 like
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 to
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 parent to
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 the minimal
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.
If
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, Andrew
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
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 fact
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
-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 will call
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 how
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]
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?
Not
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 it
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
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 pages.
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
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 create
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 the
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
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,
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 speedup
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
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 about
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
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? Not sure -- I'm
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
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
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
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
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
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 error on
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
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 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
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 buy into a
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 your
backup.
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 it
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
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.
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
[ 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
\g
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
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
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 semantics,
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 data
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
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 trying to
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 strikes me that
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
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.
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
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
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
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
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
1 - 100 of 139 matches
Mail list logo
