here for libpqtypes using events. pgfoundry is still using the older
object hooks version.
http://libpqtypes.esilo.com/libpqtypes-events.tar.gz
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
Index: src/interfaces/libpq/Makefile
Andrew Chernow wrote:
This is an updated version pf the libpqevents patch. See
http://archives.postgresql.org/pgsql-hackers/2008-09/msg00153.php
for details. The only change I didn't make yet is the event 'name'. I
have put it in and taken it out twice now, so a firm 'put
Heikki Linnakangas wrote:
Andrew Dunstan wrote:
- or maybe provide a .bat file or perl script that would work as na
archive_command on Windows.
We're not talking about archive_command. We're talking about the thing
that copies files to the directory that pg_standby polls.
Er, that's
under Windows as
well, at least enough to cover this particular issue.
A Perl script using the (standard) File::Copy module along with the
builtin function rename() should be moderately portable. It would to be
nice not to have to maintain two scripts.
cheers
andrew
--
Sent via pgsql
. Is it possible
to do this:
send async(copy table to foo)
send async(copy table to bar)
send async(copy table to baz)
Where all three copies are happening in the background?
IIRC, libpq doesn't let you have more than one async query active at one
time.
cheers
andrew
--
Sent via pgsql-patches
and be done - or maybe provide a .bat file or perl script that
would work as na archive_command on Windows.
cheers
andrew
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
.
I'd even be happier with --schema-part-1 and --schema-part-2 if we can't
find some more expressive way of designating them.
cheers
andrew
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
equivalent calls that we are doing on Linux and *BSD for example? I
suspect they probably don't ;-)
cheers
andrew
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
on any
platform. AIUI, this patch just implements what we do on platforms like
Linux or *BSD.
cheers
andrew
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
... parameterTypes)
Well, ... is really more the equivalent of your variadic keyword, I think.
public Method getMethod(String name, Class[] ... parameterTypes)
would mean each variadic argument would be an array of Class.
cheers
andrew
--
Sent via pgsql-patches mailing list
that takes 2 arrays as arguments?
This proposal strikes me as half-baked. Either we need proper and full
support for variadic functions, or we don't, but I don't think we need
syntactic sugar like the above (or maybe in this case it's really
syntactic saccharine).
cheers
andrew
--
Sent via pgsql
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
What would you consider proper and full support?
I don't know. But this doesn't feel like it.
That's a fairly weak argument for rejecting a patch that provides a
feature many people have asked
this, in fact,
so there's some precedent. That would mean that your first would
actually mean each variadic arg has to be an array of ints, which we
might well want to provide for.
So with that modification I'll be lots happier with the feature.
cheers
andrew
--
Sent via pgsql-patches
cp
instead, for archive_command. The latter does behave sanely w.r.t.
forward slashes.
cheers
andrew
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Tom Lane wrote:
multi-object DROP IF NOT EXISTS would fail to perform as expected.
Surely this would be a noop :-)
cheers
andrew
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http
not at all belong in pg_dump.
cheers
andrew
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
. Does your
foreign database not support import via CSV or XML? Postgres can now
produce both of these for any arbitrary query.
cheers
andrew
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
a valid instanceData whenever libpq returns a result,
assuming they registered a callback that allocates instance data during a
resultcreate event.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
4. add a setter for result instance data
- There should also be a PQsetInstanceData(PGconn*, ...)
- I see no need for a passThrough setter
Check, though I assume we're not expecting PQsetInstanceData to
propagate to previously
.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
libpq-events.tgz
Description: application/compressed
Index: src/interfaces/libpq/Makefile
===
RCS file: /projects/cvsroot/pgsql/src/interfaces/libpq/Makefile,v
Bruce Momjian wrote:
Andrew Dunstan wrote:
Not sure why ware are not. Should we enabled that code on Win32 and see
how it works? Can you test it? Was it some MinGW limitation? I do see
isatty() being used on lots of platforms.
This is kind of odd. Ah, I bet it came from libpq's
for with
the kluge (without really understanding why we had to).
Anyway, all is good now, as the buildfarm shows.
cheers
andrew
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Merlin Moncure wrote:
On Sat, May 17, 2008 at 8:28 AM, Andrew Chernow [EMAIL PROTECTED] wrote:
Here is an updated patch for what was called object hooks. This is now
called libpq events. If someone has a better name or hates ours, let us
know.
Let's decide where to go with this. We have
PGEVT_RESULTDESTROY has a corresponding PGEventResultDestroy structure.
The PGEventProc function's 2nd argument is void *info. The first
argument is an event id which tells the proc implementor how to cast the
void *. This replaced the initial va_arg idea.
--
Andrew Chernow
eSilo, LLC
every bit counts
. In the above case,
ENOMEM seems like a good fit.
Also, maybe you should check the passed in mutex pointer. If its NULL,
you could return EINVAL.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make
of this is getting quite a long way from what was in the commitfest
queue. Do we still want to try to get this in this cycle, or should it
be marked returned to author for more work?
cheers
andrew
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
All of this is getting quite a long way from what was in the commitfest
queue. Do we still want to try to get this in this cycle, or should it
be marked returned to author for more work?
So far I think it still falls within
previous patches do not include a
passthrough/user-pointer feature because libpqtypes didn't need it.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http
PGEVT_RESULTCREATE:
{
void *data = makeresultdata()
if(!data)
return FALSE;
((PGEventResultCreate *)evtInfo)-stateData = data;
break;
}
}
return TRUE;
}
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Andrew Chernow
eSilo, LLC
every
and an out-of-memory
failure occurs.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
simple makes it not worth the effort
in the first place.
Welcome to UI development. There is always *far* more argument of minor
matters of appearance than over anything else, in my experience.
cheers
andrew
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make
when registering hooks,
rather than supplying a hook name.
cheers
andrew
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
*, const PGhookHandle);
void *PQresultHookData(PGresult *, const PGhookHandle);
We will send in an updated patch.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http
Andrew Dunstan wrote:
Tom Lane wrote:
It might work to use the address of the hook callback function as
a key for retrieving the associated void * pointer. You'd need to
not register the same callback function more than once per object,
but from what I gather here you don't need
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
There can be cases to use the same callbacks, although unlikely. To
completely avoid collisions, the below would work:
Still looks like overdesign to me. If we use the hook function address
we solve the problem with no extra notation
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
Which callback do we use as the key? Currently, none are required (only
the name was required). We have to choose one callback that must be
provided.
What? I thought what you wanted back was the void * pointer that had
been
to Postgres 7.4 :)
I think you must have been out in the sun too long.
Just look at the pg_dump code if you want something of an idea of what
this would involve.
cheers
andrew
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
Which callback do we use as the key? Currently, none are required (only
the name was required). We have to choose one callback that must be
provided.
What? I thought what you wanted back was the void * pointer that had
been
David Fetter wrote:
On Thu, May 15, 2008 at 06:55:31PM -0400, Andrew Dunstan wrote:
David Fetter wrote:
I hate to bike-shed this even further, but I'd like to make those
incompatibility messages just go away by making 8.4's psql (and
all those going forward) support every living
Alvaro Herrera wrote:
Andrew Dunstan wrote:
Second, it's not nearly as easy as that:
. new commands have been added
. postgres features have been added
. catalogs have changed
Well, this just means a different piece of SQL needs to be sent for a
command depending on the server
Alvaro Herrera wrote:
Andrew Dunstan escribió:
The thing that is a bit disturbing is that the whole style of this
scheme is very different from the fairly simple APIs that the rest of
libpq presents. It's going to make libpq look rather odd, I think. I
would have felt happier
at the code with Andrew C (he'll be
in in a bit)...but this might be doable.
The hook callback functions allow the hook implementor to receive
created/destroyed events about a PGconn and PGresult (PQreset as well). The
hook implementor has the option of associating some memory with either
. The hook data is NOT isolated to callback
functions. It is memory that is publically accessible, outside hook
implementations.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your
), let us know.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
Index: exports.txt
===
RCS file: /projects/cvsroot/pgsql/src/interfaces/libpq/exports.txt,v
retrieving revision 1.19
diff -C6 -r1.19 exports.txt
level.
Your review should help enormously.
Stephen, perhaps you would like to work with him.
cheers
andrew
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
to the output of \dT,
which will only be used by enum types. That seems rather ... cluttered.
cheers
andrew
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I notice that this patch adds an Elements column to the output of \dT,
which will only be used by enum types. That seems rather ... cluttered.
But it'll only be in \dT+ anyway
David Fetter wrote:
On Sun, May 04, 2008 at 07:49:25PM -0400, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
But it'll only be in \dT+ anyway, no?
Not in this patch.
Hmmm ... given that a long list of enum members would bloat
version attached with schema-qualification.
Committed with slight editorialization and a consequent docs change.
cheers
andrew
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Peter Eisentraut wrote:
Andrew Dunstan wrote:
This patch should fix things for both sets of changes. And it
demonstrates pretty much what you need to do for config options for MSVC.
Btw., it is quite easily possible to use the autom4te tracing facility to
parse the configure.ac
.
cheers
andrew
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
and XLOG_SEG_SIZE
into the domain of configurable stuff, too.
This patch should fix things for both sets of changes. And it
demonstrates pretty much what you need to do for config options for MSVC.
If there's no objection I will apply shortly.
cheers
andrew
Index: src/include
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
! print O #define RELSEG_SIZE ,
! (1024 / $self-{options}-{blocksize}) *
! $self-{options}-{segsize} * 1024, \n;
This doesn't look quite right; unless the arithmetic is being done in
floating point? I
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
This doesn't look quite right; unless the arithmetic is being done in
floating point? I had it like this in configure.in:
RELSEG_SIZE=`expr '(' 1024 '*' ${segsize} / ${blocksize} ')' '*' 1024
- indeed the query in
it looks eerily familiar :-)
However, I'm wondering if we should wait until a possible rework of the
mechanics of enums as recently discussed? Or we could put it in and that
way it would have to be redone when enums are rejigged.
cheers
andrew
--
Sent via pgsql-patches
(try 2)
Here is an updated patch that applies to HEAD.
I will update the wiki.
(What is the maximum attachment size that -patches will accept?)
cheers
andrew
I wrote:
This patch by Golden Lui was his work for the last Google SoC. I was
his mentor for the project. I have just realised
.
It seems very unlikely to me.
cheers
andrew
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Applied, Thanks.
wiki updated.
cheers
andrew
ITAGAKI Takahiro wrote:
Peter Eisentraut [EMAIL PROTECTED] wrote:
Then try using %lu and no casts. That should get rid of the warnings the
proper way.
Ok, I rewrote it to use %lu for format strings.
Jeremy Drake [EMAIL PROTECTED
worked before. Anyway,
patch applied back as far as 8.2.
cheers
andrew
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
and PQresultHookData can be removed. There
functionality can be reproduced by an API user issuing PQobjectHooks or
PQresultObjectHooks and manually looking for there hook (normaly to get
at the hook-data). Basically, an API user would do themselves what
PQhookData is doing.
--
Andrew Chernow
eSilo, LLC
every
Andrew Chernow wrote:
Here is an updated version of the object hooks patch. It now supports a
list of hooks for a PGconn, and PGresult. This had to re-introduce the
concept of hook name. Being that there is now a list, you need a way to
reference an item of that list.
Also added
library not loaded: call PQtypesLoad;
}
// end user
#include libpqtypes.h // pqtypes typedefs, includes libpq-fe.h
PQtypesLoad(); // call before using libpq
res = PQparamExec(conn, param, .);
The library size issue is resolved. I never heard any complaints about this
approach. Andrew Dunstan
Merlin Moncure wrote:
On Fri, Apr 11, 2008 at 1:47 PM, Andrew Chernow [EMAIL PROTECTED] wrote:
Here are the changes to libpq. It adds the ability to register an Object
Hook and create a home-grown result. Patch adds 4 functions.
We changed the name of PQresultSetFieldValue to PQsetvalue
.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
Index: fe-connect.c
===
RCS file: /projects/cvsroot/pgsql/src/interfaces/libpq/fe-connect.c,v
retrieving revision 1.357
diff -C6 -r1.357 fe-connect.c
*** fe-connect.c31
the required changes to pqtypes; some work has already been done.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
Index: src/interfaces/libpq/exports.txt
===
RCS file: /projects/cvsroot/pgsql/src/interfaces/libpq
bound to process that created it, it still carries
significant overhead compared to using win32 CRITICAL_SECTIONs.
The attached patch replaces the win32 mutex calls with critical section
calls. The change will not affect the behavior of the windows
pthread_xxx functions.
--
Andrew Chernow
only put it there in case it is
ever needeed. BTW, I just noticed the commented destroy call forgot to
free(*mp) ... ooppssseee.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
The attached patch replaces the win32 mutex calls with critical section
calls. The change will not affect the behavior of the windows
pthread_xxx functions.
Why have you defined the lock/unlock functions as willing to fall
through
Tom Lane wrote:
Silently not locking is surely
not very safe.
Here is the dump code version of the patch. If anyone wants the return
value idea, let me know.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
Index: src/port/pthread-win32.h
Andrew Chernow wrote:
Tom Lane wrote:
Silently not locking is surely
not very safe.
Here is the dump code version of the patch. If anyone wants the return
value idea, let me know.
A more graceful solution would
daveg wrote:
On Fri, Apr 11, 2008 at 06:25:53PM -0400, Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
A more graceful solution would be to print something to stderr and then
exit.
stderr doesn't exist, or point to a useful place, in many environments.
And a forced exit
stat elsewhere? Then use safe_stat at the places you consider
critical.
cheers
andrew
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
interested in the third one here, and so, yes, the
ball should be in the author's court, not yours. I don't see any reason
for you to move items from one queue to another like that. It just looks
like it's making work.
cheers
andrew
--
Sent via pgsql-patches mailing list (pgsql-patches
is that we support C89, which might be a bit out of
date, but then we try not to obsolete platforms if possible.
cheers
andrew
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
of this idea because it breaks apart code
that is very related. Although, it is doable.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
Andrew Chernow wrote:
Joe Conway wrote:
Alvaro Herrera wrote:
Merlin Moncure escribió:
Yesterday, we notified -hackers of the latest version of the libpq
type system. Just to be sure the right people are getting notified,
we are posting the latest patch here as well. Would love to get some
hasn't sent in a patch for an undiscussed feature ;-)
cheers
andrew
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Robert Treat wrote:
On Thursday 03 April 2008 19:08, Andrew Dunstan wrote:
Joshua D. Drake wrote:
Theo Schlossnagle wrote:
First whack at exposing the start and finish checkpoint times into
SQL.
Why is that useful?
For knowing how long checkpoints
(and, as Tom has pointed out,
this patch doesn keep it historically any way).
I think there is quite possibly a good case for keeping some diagnostics
in a table or tables, on a rolling basis, maybe. But then that's a
facility that needs to be properly designed.
cheers
andrew
--
Sent via pgsql
Theo Schlossnagle wrote:
Has this feature been discussed on -hackers? I don't recall it (and
my memory has plenty of holes in it), but I'm sure that after
attending my talk last Sunday Theo hasn't sent in a patch for an
undiscussed feature ;-)
Andrew: I don't think this feature has
impressed by
our function body as a string mechanism.
cheers
andrew
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Tom Lane wrote:
One question: should \df really list *all* nonsystem functions? Or just
the ones that are visible in your search path? I'd be inclined to say
the second.
+1 (although maybe that discussion belongs on -hackers, or even -general)
cheers
andrew
--
Sent via pgsql
.
cheers
andrew
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
to for reasons of
dependency. Not sure that applies here.
cheers
andrew
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
of patches
waiting for application.
cheers
andrew
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Simon Riggs wrote:
On Mon, 2008-03-10 at 08:24 -0400, Andrew Dunstan wrote:
Simon Riggs wrote:
As Greg mentions on another thread, not all patches are *intended* to be
production quality by their authors. Many patches are shared for the
purpose of eliciting general feedback. You
Heikki Linnakangas wrote:
Andrew Dunstan wrote:
Another question that occurred to me - did you try using strpbrk() to
look for the next interesting character rather than your homegrown
searcher gadget? If so, how did that perform?
It looks like strpbrk() performs poorly:
Yes
Heikki Linnakangas wrote:
Andrew Dunstan wrote:
I'm still a bit worried about applying it unless it gets some
adaptive behaviour or something so that we don't cause any serious
performance regressions in some cases.
I'll try to come up with something. At the most conservative end, we
after the patch,
perhaps even better.
This looks sane enough, and worked for me in testing, so I'm going to
apply it shortly. I'll probably add a comment or two about how the loops
interact.
cheers
andrew
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make
- that
includes both quote chars and dot)
cheers
andrew
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.orgextra=pgsql-patches
to the ASCII
range? Especially if the client encoding is multibyte ...
In the commonest case these are both either or '. I would not have any
objection to requiring them to be ASCII chars.
cheers
andrew
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes
Heikki Linnakangas wrote:
Andrew Dunstan wrote:
Heikki Linnakangas wrote:
Another update attached: It occurred to me that the memchr approach is
only safe for server encodings, where the non-first bytes of a
multi-byte character always have the hi-bit set.
We currently make
Heikki Linnakangas wrote:
Andrew Dunstan wrote:
I'm still a bit worried about applying it unless it gets some
adaptive behaviour or something so that we don't cause any serious
performance regressions in some cases.
I'll try to come up with something. At the most conservative end, we
have the bad regression that shows up with 8
escapes per line.
I'd be inclined just to look at the first buffer of data we read in, and
make a one-off decision there, if we can get away with it. Then the cost
of testing is fixed rather than per line.
cheers
andrew
--
Sent via pgsql
Tom Lane wrote:
Having to have two extra hook functions for every variable
seems like a lot of notational overhead for not much gain.
+1
cheers
andrew
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http
and change
strategy accordingly?
cheers
andrew
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.orgextra=pgsql-patches
Alvaro Herrera wrote:
Both done -- I backpatched all the way down to 7.4 (and later I noticed
that the only 7.3 BF members are NetBSD).
Haven't we declared 7.3 at EOL anyway?
cheers
andrew
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your
Alvaro Herrera wrote:
Andrew Dunstan wrote:
Alvaro Herrera wrote:
Both done -- I backpatched all the way down to 7.4 (and later I noticed
that the only 7.3 BF members are NetBSD).
Haven't we declared 7.3 at EOL anyway?
That's why I didn't backpatch
as well.
We also tried to provide as much protection as possible ... in the spirit of the
backend.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http
reliably store such bytes.
Reliably is arguably misleading here.
cheers
andrew
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your Subscription:
http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.orgextra=pgsql-patches
1 - 100 of 831 matches
Mail list logo
