Tilo Schwarz wrote:
What about the Python approach: The literal text is enclosed either in a pair
of three single quotes or three double quotes. So you can do (e.g. in the
python shell)
It'll only make plpyhon functions harder to write, if you need to use
longstring quoting INSIDE your plpython
On Fri, 12 Sep 2003, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > OK, here is an Opteron/Itanium patch that might work.
> >
> > [having now read both patches]
> >
> > Assuming that this covers the issues (what other OSes might run on
> > 64-bit machi
Manfred Spraul <[EMAIL PROTECTED]> writes:
> Is the Itanium tas implementation correct?
FWIW, this evening I did a few dozen iterations of "make check" parallel
regression tests on a 4-way Itanium box at Red Hat's Toronto office,
working from CVS-tip sources. No sign of problems. That's not a pr
[EMAIL PROTECTED] ("Matthew T. O'Connor") writes:
> OK, well as we wait on the fix for the stats system, let me submit my
> patch for pg_autovacuum. This patch assumes that the stats system will
> be fixed so that all inserts, updates and deletes performed on shared
> tables reguardless of what da
Manfred Spraul wrote:
Is the Itanium tas implementation correct? I think it should be
xchg4.aqv instead of just xchg4 - as far as I know a normal atomic
exchange is is not a memory barrier on Itanium. At least the Linux
kernel version contains "cmpxchg4.aqv".
Sorry for the noise, I'm wrong:
Ita
Hello:
1st Beta 1 version of PGSqlClient an ADO.NET Data Provider for
PostgreSQL 7.4+ released.
Beta 1 ( 12-09-2003 )
- - -- -- -
* Better fit to ADO.NET.
* Simple Transport Layer security ( TLS 1.0 ) implementation
It's used yet for both TLS and non-TLS connections but it's not finis
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
He is uncomfortable with the port/*.h changes at this point, so it seems
I am going to have to add Itanium/Opteron tests to most of those files.
Why don't you try to put together a proposed patch of that
[EMAIL PROTECTED] ("Matthew T. O'Connor") writes:
> So we would have a problem if commands that effect these tables are done
> from lots of different databases. In reality, I don't think these
> tables change that much (pg_database, pg_shadow, and pg_group), and most
> of commands that do effect t
James Pye writes:
> Type conversion
>
> plpython's current type conversion implementation appears to be dependent
> on strings as the common format. This is fine, but not very extensible as
> is, unless you don't mind explicitly parsing strings inside each function
> that takes an unsupporte
> Wow, that is strange. Someone else told me NetBSD supports threads, and
> doesn't need any special compile flags, but of course, it has to have
> pthread.h to support threads. NetBSD 1.6.1 is very current, so it isn't
> an old OS.
NetBSD-1.6.1 doesn't have native thread. NetBSD-current has i
--On Friday, September 12, 2003 13:30:38 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Larry Rosenman wrote:
> Wow, that is strange. Someone else told me NetBSD supports threads,
> and doesn't need any special compile flags, but of course, it has to
> have pthread.h to support threads. NetBS
Larry Rosenman wrote:
> > Wow, that is strange. Someone else told me NetBSD supports threads, and
> > doesn't need any special compile flags, but of course, it has to have
> > pthread.h to support threads. NetBSD 1.6.1 is very current, so it isn't
> > an old OS.
> >
> > Can you compile if you rem
On Fri, 2003-09-12 at 13:06, Tom Lane wrote:
> > I can hardwire in something to hedge this off like setting the threshold
> > for shared tables much much lower than normal thresholds. I could also
> > do something more complicated and try to aggregate all the activity seen
> > by all the databases
--On Friday, September 12, 2003 13:03:33 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Larry Rosenman wrote:
-- Start of PGP signed section.
--On Friday, September 12, 2003 12:18:52 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
>
> I need someone running NetBSD to read the top of
> src/tool
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> So we would have a problem if commands that effect these tables are done
> from lots of different databases. In reality, I don't think these
> tables change that much (pg_database, pg_shadow, and pg_group), and most
> of commands that do effect t
Larry Rosenman wrote:
-- Start of PGP signed section.
>
>
> --On Friday, September 12, 2003 12:18:52 -0400 Bruce Momjian
> <[EMAIL PROTECTED]> wrote:
>
> >
> > I need someone running NetBSD to read the top of
> > src/tools/test_thread_funcs.c and compile and run that function and
> > report the
On Fri, 2003-09-12 at 12:46, Tom Lane wrote:
> How will it act with shared tables if the stats system isn't fixed?
> We may decide that tracking shared tables correctly will have to wait
> for 7.5.
The behavior in the patch will vacuum a shared table only from
template1, and only analyze from all
> > ... then @autoconf me harder@ could be used as the start and
> > ending token,
>
> Hm, I should have read your message more carefully --- I missed the
> bit at the middle where you propose nearly the same idea I had ;-).
> But the flex patterns you wrote don't actually support this do they?
T
--On Friday, September 12, 2003 12:18:52 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
I need someone running NetBSD to read the top of
src/tools/test_thread_funcs.c and compile and run that function and
report the results.
I have access to one NetBSD system on an Alpha:
$ uname -a
NetBSD mil
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> Even if this the stats system isn't fixed, this patch still is much
> better about monitoring system tables that aren't shared, so it's an
> improvement no matter what.
How will it act with shared tables if the stats system isn't fixed?
We may de
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > As part of my spinlock testing, I noticed that we test for __cpu__ when
> > using gcc, and __cpu when not using gcc. However, I see that my i386
> > gcc 2.95 defines both (shown using src/tools/ccsym):
>
> gcc only documents the __foo__ versi
On Fri, 2003-09-12 at 09:35, Bruce Momjian wrote:
> Matthew T. O'Connor wrote:
> > I made a patch to fix this, but in testing it I noticed that the stats
> > system doesn't work on shared tables as I was expecting it too (as my
> > latest patch requires it too :-). It treats instances of shared tab
Bruce Momjian writes:
> As part of my spinlock testing, I noticed that we test for __cpu__ when
> using gcc, and __cpu when not using gcc. However, I see that my i386
> gcc 2.95 defines both (shown using src/tools/ccsym):
gcc only documents the __foo__ version, so there is a small reason to lean
I need someone running NetBSD to read the top of
src/tools/test_thread_funcs.c and compile and run that function and
report the results.
Thanks.
---
Christopher Kings-Lynne wrote:
> FreeBSD 4.8/i386:
>
> Your gethostbyname
You should find that the next daily snapshot and beta3 will properly
detect Opteron/Itanium on your platform.
I don't think we can help you with the compiler bugs, however. ;-)
---
Jeroen Ruigrok/asmodai wrote:
> -On [2003
Andrew Dunstan wrote:
> Bruce Momjian wrote:
>
> >Because MinGW/Msys doesn't come with flex/bison by default, I have added
> >those derived files to the WIN32_DEV branch in CVS. It makes it easier
> >for people to install _just_ MinGW and compile PostgreSQL on Win32. The
> >branch will live for
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, here is an Opteron/Itanium patch that might work.
[having now read both patches]
Assuming that this covers the issues (what other OSes might run on
64-bit machines within 7.4's lifespan?) I think there is little question
that this is the more conser
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > OK, here is an Opteron/Itanium patch that might work.
>
> [having now read both patches]
>
> Assuming that this covers the issues (what other OSes might run on
> 64-bit machines within 7.4's lifespan?) I think there is little questio
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I'd like to see pg_dump use this mechanism for quoting, at least for
function bodies. I guess it could retrieve the text and then keep
generating delimiters until it found one that didn't occur inside the
text.
Right, that was w
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Does this say that Darwin on something other than PPC doesn't have
> > spinlocks? Is that going to hit a spinlock define, or fall through?
>
> It says that darwin.h is broken, and always has been, for non-PPC
> builds. Since there i
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Does this say that Darwin on something other than PPC doesn't have
> spinlocks? Is that going to hit a spinlock define, or fall through?
It says that darwin.h is broken, and always has been, for non-PPC
builds. Since there is no non-PPC Darwin (afaik),
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > I'd like to see pg_dump use this mechanism for quoting, at least for
> > function bodies. I guess it could retrieve the text and then keep
> > generating delimiters until it found one that didn't occur inside the
> > text.
>
> Rig
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > He is uncomfortable with the port/*.h changes at this point, so it seems
> > I am going to have to add Itanium/Opteron tests to most of those files.
>
> Why don't you try to put together a proposed patch of that kind, and
> then we ca
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I'd like to see pg_dump use this mechanism for quoting, at least for
> function bodies. I guess it could retrieve the text and then keep
> generating delimiters until it found one that didn't occur inside the
> text.
Right, that was what I had in min
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > As part of my spinlock testing, I noticed that we test for __cpu__ when
> > using gcc, and __cpu when not using gcc.
> > ...
> > So, I wonder if we should be testing _just_ for __cpu, perhaps starting
> > in 7.5.
>
> I might be all we
Bruce Momjian <[EMAIL PROTECTED]> writes:
> As part of my spinlock testing, I noticed that we test for __cpu__ when
> using gcc, and __cpu when not using gcc.
> ...
> So, I wonder if we should be testing _just_ for __cpu, perhaps starting
> in 7.5.
I might be all wet on this, but I had the idea th
Bruce Momjian <[EMAIL PROTECTED]> writes:
> He is uncomfortable with the port/*.h changes at this point, so it seems
> I am going to have to add Itanium/Opteron tests to most of those files.
Why don't you try to put together a proposed patch of that kind, and
then we can look to see how big and ug
Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > 'K, now, I know we acquire all our shared_buffers on startup now ... do we
> > do the same with semaphores?
>
> Yes.
>
> > If we do acquire at the start, would it not be trivial to add a message to
> > the startup messages, base
Hi,
after Beta1 I'd reported problems in the regression tests under Digital
Unix/Tru64. Unfortunately I had no time to report about my tests and to
check Beta2 before now.
Beta2 builds fine on Digital Unix 4.0G:
template1=# SELECT version();
version
-
On Fri, Sep 12, 2003 at 08:57:16AM -0400, Merlin Moncure wrote:
> Here: http://unxutils.sourceforge.net/ are ports of several unix
> utility programs (including bison and flex) for win32. From my
> experiences compiling the Peer Direct port, this is the easiest way to
> get started.
OK, I'll thro
--On Friday, September 12, 2003 09:53:10 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
As part of my spinlock testing, I noticed that we test for __cpu__ when
using gcc, and __cpu when not using gcc. However, I see that my i386
gcc 2.95 defines both (shown using src/tools/ccsym):
__GN
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> 'K, now, I know we acquire all our shared_buffers on startup now ... do we
> do the same with semaphores?
Yes.
> If we do acquire at the start, would it not be trivial to add a message to
> the startup messages, based on #_of_semaphores != max_conn
Tom Lane wrote:
After sleeping on it, I do think that tying the mechanism to newlines
is just unnecessary complication. I'm currently leaning to an idea that
was suggested yesterday by (I think) Andreas: let the quote start marker
be a token of the form
dollarsign zero-or-more-letters dol
Sean Chittenden <[EMAIL PROTECTED]> writes:
> ... then @autoconf me harder@ could be used as the start and ending
> token,
Hm, I should have read your message more carefully --- I missed the bit
at the middle where you propose nearly the same idea I had ;-). But the
flex patterns you wrote don't
On Fri, 12 Sep 2003, Tom Lane wrote:
> I'm currently leaning to an idea that was suggested yesterday by (I
> think) Andreas: let the quote start marker be a token of the form
> dollarsign zero-or-more-letters dollarsign
> and let the quote body extend to the next occurrence of the identical
Marc G. Fournier wrote:
>
>
> On Fri, 12 Sep 2003, Tom Lane wrote:
>
> > "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > >> If we force people to give a --without-spinlocks config option to build
> > >> that way, then `pg_config --configure' will reveal the dirty deed ...
> >
> > > That's not
On Fri, 12 Sep 2003, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> >> If we force people to give a --without-spinlocks config option to build
> >> that way, then `pg_config --configure' will reveal the dirty deed ...
>
> > That's not quite what I meant :) Right now, if I un
Bruce Momjian wrote:
> Prompted by confusion over Itanium/Opterion, I have written a patch to
> improve the way we define spinlocks for platforms and cpu's. It
> basically decouples the OS from the CPU spinlock code. In almost all
> cases, the spinlock code cares only about the compiler and CPU,
Tom Lane wrote:
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
I made a patch to fix this, but in testing it I noticed that the stats
system doesn't work on shared tables as I was expecting it too (as my
latest patch requires it too :-). It treats instances of shared tables
in separate databas
As part of my spinlock testing, I noticed that we test for __cpu__ when
using gcc, and __cpu when not using gcc. However, I see that my i386
gcc 2.95 defines both (shown using src/tools/ccsym):
__GNUC__=2
__GNUC_MINOR__=95
unix
__i386__
i386
__bsdi_
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Note that there is no particular need to insist on any nearby newlines.
>> If the construct is written just following an identifier or keyword,
>> then you do need some intervening whitespace to keep the $Q$ from being
>> read as part o
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
>> If we force people to give a --without-spinlocks config option to build
>> that way, then `pg_config --configure' will reveal the dirty deed ...
> That's not quite what I meant :) Right now, if I understood what Bruce
> was saying, if someone does
Tom Lane wrote:
> Note that there is no particular need to insist on any nearby newlines.
> If the construct is written just following an identifier or keyword,
> then you do need some intervening whitespace to keep the $Q$ from being
> read as part of that identifier, but I doubt this will bother
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> I made a patch to fix this, but in testing it I noticed that the stats
> system doesn't work on shared tables as I was expecting it too (as my
> latest patch requires it too :-). It treats instances of shared tables
> in separate databases as tota
Sean Chittenden <[EMAIL PROTECTED]> writes:
> Using $$[.*]\n as a lexical token is a quasi-problematic as the anchor
> is the newline, something that SQL has been free of for as long as I'm
> aware of. By using a static lexical token, such as @@, newline's
> aren't important, thus reducing the num
Marc G. Fournier wrote:
>
>
> On Fri, 12 Sep 2003, Tom Lane wrote:
>
> > "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > >> Right, though I am not sure people will know _slow_ configuration vs.
> > >> PostgreSQL is slow.
> >
> > > No, but definitely something for those discussion performance
Matthew T. O'Connor wrote:
> On Thu, 2003-09-11 at 18:25, Tom Lane wrote:
> > "Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> > > hrm OK. Patch forthcoming
> >
> > BTW, I am not sure it is a good idea to suppress "redundant" vacuuming
> > of shared tables in the first place. The trou
> > Below is the email that prompted me to add the derived files to
> > WIN32_DEV CVS.
>
> > However, most people don't want them in there, so I have removed them,
> > and updated the web page to recommend the nightly snapshots (which have
> > the derived files), and mentioned the tools that will
On Fri, 12 Sep 2003, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> >> Right, though I am not sure people will know _slow_ configuration vs.
> >> PostgreSQL is slow.
>
> > No, but definitely something for those discussion performance to add
> > to their checklist :)
>
> > BTW
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 11, 2003 10:11 PM
To: Steve Novick
Cc: PostgreSQL-development; PostgreSQL Win32 port list
Subject: Re: [HACKERS] Win32 native port
> Below is the email that prompted me to add the derived files to
On Thursday 11 September 2003 20:13, Peter Eisentraut wrote:
> Darko Prenosil writes:
> > Here is the idea: there is problem to find out in which encoding is using
> > mo file, but we can force gettext to serve known encoding for example
> > utf8. After that we can always convert from unicode to cl
On Thu, 2003-09-11 at 18:25, Tom Lane wrote:
> "Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> > hrm OK. Patch forthcoming
>
> BTW, I am not sure it is a good idea to suppress "redundant" vacuuming
> of shared tables in the first place. The trouble with doing so is that
> if you only
62 matches
Mail list logo
