Robert Treat wrote:
Someone did it but it didn't catch fire.
I think what will catch fire in a big way is plphp. Managers will like
an all php platform that is extremely capable and productive.
Developers will enjoy php's natural syntax and agnostic approach to
programming. PHP5, when it
Peter Eisentraut wrote:
The central problem I have is this: How do we deal with the fact that
an XML datum carries its own encoding information?
Maybe I am misunderstanding your question, but IMO postgres should be
treating xml documents as if they were binary data, unless the server
takes on
Andrew Dunstan wrote:
I think I agree with Rod's opinion elsewhere in this thread. I guess
the
philosophical question is this: If 2 XML documents with different
encodings have the same canonical form, or perhaps produce the same
DOM,
are they equivalent? Merlin appears to want to say no, and I
Hannu Krosing wrote:
IIRC, the charset transformations are done as a separate step in the
wire protocol _before_ any parser has chance transform or not.
Yep. My point is that this is wrong. I think of XML the same way I
think of a zip file contains a text document. Postgres does not unzip a
Claudio Natoli wrote:
FWIW, in a multithreaded version of postgres I'm fooling around with,
I
replaced the recv call (where backends spend most of their time
waiting)
which a select(small timeout)/SleepEx(0) busy loop, which calls to
recv
when ready. Works just fine.
Ok, that makes perfect
Hannu Krosing wrote:
In that case, treat the XML document like a binary stream, using
PQescapeBytea, etc. to encode if necessary pre-query. Also, the XML
domain should inherit from bytea, not varchar.
why ?
the allowed characters repertoire in XML is even less than in varchar.
Yes,
Greg Stark wrote:
Personally I don't see any point in xml, but if there was a standard
query
protocol then a client could send queries to any database that
supported
it
without using any libraries. That might be useful. Of course you could
do
that
without xml, but people seem to get more
Peter Eisentraut wrote:
I think output XML is just buzz. Give us a real use scenario and an
indication that a majority also has that use scenario (vs. the other
ones listed above), then we can talk.
Consider:
create table person (name varchar primary key, age int);
create table account
Hello,
I think it's safe to say there is a working implementation of a signal
handler. The one tricky part left is to identify some smart places for
the backend to check the awaiting signal queue. The first one is easy:
switch recv() with select() with a reasonable timeout and a poll.
If and
Kevin Brown wrote:
I have no idea whether or not this approach would work in Windows.
The win32 API has ReadFileScatter/WriteFileScatter, which was developed
to handle these types of problems. These two functions were added for
the sole purpose of making SQL server run faster. They are always
Most of the new features are new database tools, etc. That has always
been a strong point with SQL server. IMO, the weak point of the
database (aside from the vendor and the price), is a lack flexibility of
the client APIs and the stored procedure syntax.
The interesting features are the xml
Does anybody think there might be some interest in an ISAM driver for
PostgreSQL? I've written a functional alpha that allows PostgreSQL to
be a drop in (or as easy as reasonably possible) replacement for an ISAM
file system driving a COBOL application. It is a STL based thin wrapper
around
Greg Stark wrote:
imposed no such conditions. If Microsoft wanted to release a Microsoft
Postgresql under a completely proprietary license they would be free
to do
I have often wondered, in a completely off-topic and unproductive sort
of way, if exactly that has not already been done by an
Today Michael Steil and I have tested PostgreSQL 7.4.1 on Nintendo Game
Cubes.
All regression test (but stats - stats collector was off instead of on)
have passed successfully.
What about the XBOX? :-)
Merlin
---(end of broadcast)---
TIP 8:
Bruce Momjian wrote:
I am timing small queries, and found that a PREPARE/EXECUTE of SELECT
1 takes about 1.2ms on my machine. A normal SELECT doesn't take much
longer, so I am wondering why a simpler query isn't faster.
Looking at log_executor_stats, I see the following. Execute shows
Tom Lane wrote:
The optimizer has no knowledge of specific operators except what it
finds in the system catalogs. It has no way in general to determine
that a comparison involving nonconstant values must always fail.
Even if we could do it, I am dubious that it would be worth expending
the
The problem with gprof is that I am going to see all the backend
startup
stuff too, no? Is there a way to get a dump just the run of the
query?
I was sort of lurking on this thread, waiting to see what became of
it.
Did
nobody actually come to a conclusion on what that last msec was
The compilers from Microsoft and Borland atleast aren't
compatible.
But that shows up as link errors, not at runtime, right?
Correct. Microsoft and Borland use different library packaging formats,
COFF and OMF. However (non C++) DLLs are compatible and you can extract
a static lib from a
J. Andrew Rogers wrote:
No. The greatest strength of Postgres, marketing-wise, are technical
and is what drives its growth today. I think most of the ease-of-use
issues are in the packaging of the larger Postgres product and
mid-level
developer documentation, both of which seem to be
Two very minor points with the new alter table (not sure if they are
even bugs are have already been addressed).
1. alter table alter type on a clustered index seems to drop the cluster
(by design)?
2. alter table cluster on seems to give a strange error message of the
index name is really the
Is it feasible or practical to consider adding ALTER DOMAIN TYPE type?
(basically following the same rules as ALTER TABLE).
I don't mind bringing down all the views before I do this, it would be
just great if you could change domains from a centralized location.
Oracle offers this feature...
Tom Lane wrote:
I tweaked things so that the clustered flag is preserved for indexes
that aren't directly affected by the ALTER TYPE. It would take more
work to preserve the setting for an index that is rebuilt by ALTER
TYPE,
and I'm not even sure that it's sensible --- the new index could
Yes. This is something I was going to look at doing in the next
release.
Quick question:
With your potential changes, you would then be able to alter a domain
that is involved in RI constraints between 2 or more tables without
bringing down the constraints, yes? This would be great :)
Merlin
Tom Lane wrote:
If we were willing to abuse the ALTER TABLE syntax some more, it would
be possible to support changing the datatypes of f1 and f2
simultaneously, thereby allowing the above to work. The
infrastructure
for hacking multiple tables in parallel is already there in CVS tip,
but it
[EMAIL PROTECTED] wrote:
PostgreSQL. Maybe it is in the form of a web server like Samba's SWAT
utility, I don't know (A SWAT type utility could run as the PostgreSQL
I've found webmin to be pretty good swat type tool...it's lacking some
things to be a full postgres administration system, but I
[sorry for the repost...lists down? Problem may or may not be on win32
version only]
The catalog number was updated, so it was time to run initdb.
Sometime over the weekend (or since the last initdb I ran, about a
week), the source was updated which caused an AV CRASH during
I have no idea what caused the pg_depend stuff to crash.
The AV is in postgres.exe following the first SQL call in
setup_depend(). The problem is not in initdb (it hasn't changed) but
something in the backend. Changing the SQL statement made no
difference: I'd venture a guess that postgres.exe
I'll check why the rmdir command is not working as expected.
I just poked around and couldn't figure out the cause. Initdb should
either remove the directory if it created it, or remove everything
_in_
the directory if the directory already existed. I tried the rmdir/del
/s /q commands
Alvaro Herrera wrote:
The AV is in postgres.exe following the first SQL call in
setup_depend(). The problem is not in initdb (it hasn't changed)
but
something in the backend. Changing the SQL statement made no
difference: I'd venture a guess that postgres.exe crashes when *any*
make clean appears to have fixed the initdb crash :)
sorry to bother... :)
Merlin
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Bruce Momjian wrote:
Merlin Moncure wrote:
I'll check why the rmdir command is not working as expected.
I just poked around and couldn't figure out the cause. Initdb
should
either remove the directory if it created it, or remove everything
_in_
the directory if the directory
Bruce Momjian wrote:
Well, if Win32 doesn't complete by June 1, do we still do the feature
freeze? I don't want to be adding features after the freeze, that is
[...]
As I remember, we decided that we should not make decisions to extend
the feature freeze date just before the freeze date
In the current build on the anon cvs server, if I try to \d a table from
psql, the backend comes down. I played with the query a bit and
discovered any query using '~' operator in the where clause on any table
(catalog or otherwise) causes an immediate backend crash.
Can anybody confirm that
I have binary install from snapshot from the other night on WINDOWS
2000
PRO and had same problem.
well, I'm the one compiling the snapshot :), so I trying to confirm that
I have not busted anything...when did you download the snapshot, though?
I switched to gcc 3.4 yesterday, was it earlier
Merlin Moncure [EMAIL PROTECTED] writes:
In the current build on the anon cvs server, if I try to \d a table
from
psql, the backend comes down. I played with the query a bit and
discovered any query using '~' operator in the where clause on any
table
(catalog or otherwise) causes
I was playing with the Japanese win32 7.2.1 port and I noticed that select
0 / 0 caused the server to crash and restart. I understand that it is a
totally unsupported version, but it should be easy enough to check vs. the
current version. Note that select 0.0/0.0 worked fine!
Merlin
I had read on one of the newsgroups that there is a planned native port to
the win32 platform, is this true? I read most of the win32 thread off of
the dev site and it was not clear if this was true.
In either case, I would like to advocate such a port to be done, and soon,
not for any
Hmm, ever tried using a large multiuser database such as a finance
system using a Foxpro database? Network managers have been known to
murder for less... :-)
Hmm, I have, and you could imagine the result :)
It was a small system, really and everything was fine until I added my 10th
user.
How about OPTIMIZE?
eg. optimize customers
instead of analyze, could be paired with agressive
so, OPTIMIZE AGREESSIVE
very much a glass half empty, half full type thing. vacuum is not a
problem, its a solution.
Merlin
Curtis Faith [EMAIL PROTECTED] wrote in message
[EMAIL
Just a quick question... are you guys using the C runtime or the win32
API to do things like file i/o and memory allocation. If you are using
the win32 api, are you using asynchronous I/O? Generally, how much raw
win32 code do you expect to write (assumption: as little as possible).
As for
mysql does not have cygwin in the server, either static or otherwise.
We looked at the code a while back and confirmed this. mysql has a much
smaller code base than pg.
If they did, it would be a very strange deal because you can link your
app directly to the mysql server (for 200$...non GPL)
I'm not sure what version of MySQL you were looking at, but that's
certainly doesn't seem to be the case anymore. I just checked: MySQL
4.0.9 has ~435,000 LOC, PgSQL from CVS HEAD has ~372,000.
Hmm, you got me there, tho this was some time back from the last version
of the 3.x series.
Merlin
Can the ConsoleApp thing be written in C so we don't have to get an
extra C++ compiler for one file (for those who don't want to use the
Microsoft toolchain)?
Critical sections and semaphores and mutexes are all available from the
win32 API. I agree with Peter: I am not sure it is a good idea to
For Win32, in order to emulate fsync() we will need to call
FlushFileBuffers():
The supplied link does not work. FlushFileBuffers() is for flushing
files opened with CreateFile() etc.
For files opened with fopen(), call fflush().
For files opened with _open(), call _commit().
Likekly the
I'm having difficulty digging up the reference, but I think I recall
seeing something that said, roughly, on W32 there are 2 sets of buffers
- those in the user level library and those in the kernel level driver,
and FlushFileBuffers drains the first, while _commit drains both (it
includes a call
I think the fopen or _open family of functions all map directly to the
win32 API. They add a little cruft, which generally makes using them
pointless, because you have less control over security, caching, and
other such things when opening the file. There is the slight overhead
of the extra
I've tested all the win32 versions of postgres I can get my hands on
(cygwin and not), and my general feeling is that they have problems with
insert performance with fsync() turned on, probably the fault of the os.
Select performance is not so much affected.
This is easily solved with
Does anyone know whether cygwin has a setting comparable to SHMMAX,
and if so what is its default value? How about the upcoming native
Windows port --- any issues there?
From a pure win32 point of view, a good approach would be to use the
VirtualAlloc() memory allocation functions and set up a
True, but even so, 32 max connections is a bit light. I have more
pgsql databases than that on my box now. My point in my previous answer
to Tom was that you HAVE to shut down postgresql to change this. It
doesn't allocate tons of semaphores on startup,
[snip]
is this correct? I recall
Has a final decision been made if the win32 port is going to
be threaded or not?
Merlin
I think there should be a special mailing list set up called
pg-sql-win32-advocacy where people can continually harass the postgres
dev team and debate the merits of the win32 operating system. In
particular, make sure to insult them for being elitists (while at the
same time asking them to
Another way of looking at it is memory mapped files. This probably
most
closely resembles unix shared memory and is the de facto standard
way
for interprocess memory block sharing. Sadly, performance will
suffer
because you have to rely on the virtual memory system (think:
writing to
, Merlin Moncure a écrit :
I think there should be a special mailing list set up called
pg-sql-win32-advocacy where people can continually harass the postgres
dev team and debate the merits of the win32 operating system.
I realize my views about PostgreSQL are not shared by anyone, otherwize
I am trying to emulate a pessimistic locking system you would find in an
old school database file system, for example cobol. Generally, when a
cobol program tries to read a record that is locked by somebody else,
the read fails and either a message is displayed by the user or a error
handling
That's my fallback position. Obviously, this will lead to false
positives depending on server load. In my case, I'm targeting between
30-50 users so its likely to throw timeouts for various reasons other
than locks even though my queries of interest are generally select a
from b where id = c
I was referring to 10.3 in the administrator's guide, regarding the
pg_lock view. According to the documentation, the view only contains
table level locks. However, the view also contains an xid for
transactions. The unclear part, at least to me, was what the role of
the xid was in the view and
This directly answers my question (wasn't previously aware that xid
could be queried out in such a useful fashion). Not only does this
accomplish what I need, but now allows me to not use select ... for
update and stick with a transaction based locking mechanism. The 'Why'
isn't that
-Original Message-
From: Merlin Moncure
Sent: Monday, March 03, 2003 3:47 PM
To: 'Peter Eisentraut'
Subject: RE: [HACKERS] [PATCHES] XML ouput for psql
My 0.2$: keep the xml formatting rules as simple as possible and rely on
xslt to do the document markup (going out) and schemas/xslt
XSLT could be used to convert virtually any xml table format directly
into an insert statement. For me, this is better than using a
programming language plus a parser. XSLT is quite powerful and fast and
is build on top of xpath, and is a closer fit to the declarative
programming model of sql.
years in development.
Merlin
-Original Message-
From: Bob Calco [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 05, 2003 9:10 AM
To: Merlin Moncure; Alan Gutierrez
Cc: [EMAIL PROTECTED]
Subject: RE: [HACKERS] XML ouput for psql
I would like to see PostgreSQL eventually support XQuery
My experience with windows backend work is that you have to turn off all
buffering and implement your own write cache of sorts. Flushing is not
the only reason: heavy buffering of files (the default behavior) also
tends to thrash the server, because the cache does not always release
memory
-Original Message-
From: mlw [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 05, 2003 3:47 PM
To: [EMAIL PROTECTED]
Subject: [HACKERS] Aggregate rollup
I had written a piece of code about two years ago that used the
aggregate feature of PostgreSQL to create an array of integers
I haven't been able to get to it all morning.
I think its time to consider migrating off of mysql on the web server.
Merlin
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
mlw [mailto:[EMAIL PROTECTED] wrote:
I use PostgreSQL with C++ all the time. I actually have a SQL class
that
abstracts libpq and ODBC, so I'm pretty much past a lot of the how I
want to use it stuff.
What about libpq++? I have not used the thing, but if he absolutely
insists on using C++ in
Justin Clift wrote:
This is the 'proof of concept' cygwin windows build. Strangely, I
have
a newer build than the one on the ftp server. Is there a binary
version
of postgres with Jan's patch available?
Uh Oh.
When you say newer version, what gives the feeling of it being
newer?
Tom Lane wrote:
I checked into this, and indeed OS X 10.2 is behaving funny: integer
divide by zero doesn't raise any signal, it just returns a bogus
answer.
They're within their rights to do so according to the ANSI C spec
(wherein division by zero is stated to have undefined behavior).
Justin Clift wrote:
PostgreSQL 8.0
**
+ Includes PITR and the Win32 port
*snip*
I feel like the upcoming 7.4 is the most important release since the
introduction of toast, maybe even since the introduction of the sql
language. I wholeheartedly agree with your proposition.
Tom Lane wrote:
This is not C.
I can't argue that; but it will compile on a C compiler on the Microsoft
platform. I'm not sure if you were answering tongue-in-cheek, so for
the benefit of the group:
__try and __except, as far as I can tell are the only way to gracefully
handle certain events.
Doug Royer wrote:
No, try/catch does not trap division by zero unless the underlying
implementation throws an error there is nothing to catch.
I am absolutely 100% sure that you can catch int/0 with a try catch
handler (in c++) on windows platforms (when compiled with ms/borland
compiler).
If the backend can not handle the version I request, but can handle a
prior version, I'd like to know. I am planning on having handlers for
multiple protocol versions in the same memory space (I'm using
Smalltalk, BTW) so that one application can talk to various databases
of
various
Justin Clift wrote:
confidentiality level of the Win32/PITR patches at present, but I'd
guess there would be at least a few solid volunteers willing to
contribute to the Win32/PITR ports if we asked for people to step
forwards.
I'd like to help. I've been following the list for several
Peter Eisentraut writes:
Dave Page writes:
Well what I *really* need has been made quite clear in other posts,
but,
when I say resultset in the same sentence as pgAdmin, I'm referring
to
the ability to enter an arbitrary SQL query, have the results
displayed
in a grid, which can then
The big question is how to fix this on Win32. Is a test in the
integer
division routines enough? Is there a signal to catch on Win32?
After fighting with the docs a little bit, here is how to handle an
int/0 in a C application.
#include stdio.h
#include excpt.h
#include windows.h
int
I am working my way through getting the postgres win32 port (7.2.1)
compiled under MSVC. I got through the patch and the compilation, but
am having problems with the linker. Trying to link the backend, I get
43 linker errors like:
unresolved external symbol GUC-scanstr
unresolved external
I am working my way through getting the postgres win32 port (7.2.1)
compiled under MSVC. I got through the patch and the compilation, but
am having problems with the linker. Trying to link the backend, I get
43 linker errors like:
unresolved external symbol GUC-scanstr
unresolved external
Following example is with latest anonymous cvs of 7.5.
I can't get LIKE to use an index even with seq_scan = off. I'm using
the default locale and hchassis.vin_no is defined as char(17). The
hchassis table has about 250k rows in it. The non aggregate versions of
the selects have the same
Sometime between yesterday and today queries in the form of
select * from t where t.f like 'k%' have been broken so that they
never use the index (on win32, not sure about others).
On win32, at least, they have been broken for a while but this was due
to a known issue based on the locales.
Sometime between yesterday and today queries in the form of
select * from t where t.f like 'k%' have been broken so that they
never use the index (on win32, not sure about others).
On win32, at least, they have been broken for a while but this was
due
to a known issue based on the
It looks to me like you have an index of type bpchar but are
searching
with type text. I find type conversions very limited with LIKE.
I would create an index on 'vin_no' using a cast to TEXT. This should
work
on both queries.
Not in this case. Just to be sure, I created a new column as
Hmmm, snipped from your reply was the explain plan from the query
where it
was clear you were using two different character data types: bpchat
and
text. That, alone, may have been a problem.
Looking at your defaults, did you do:
initdb --locale=C somepath
I reran initdb --locale=C yesterday
Dave Page wrote:
OK, looks like the error below is a Win32 thing. The patch attached
#ifdef'd out the permissions check on the private key file as it won't
work under Windows anyway (a similar check in postmaster.c has has
already been ifdef'd out for the same reason).
Incidently, the
Now, here's a scenario that has us worried:
BEGIN
PREPARE foo AS ...
... [error]
DEALLOCATE foo [fails: already aborted by previous error]
ABORT
BEGIN
PREPARE foo AS ... [fails: foo is already defined!]
EXECUTE foo [fails: already aborted
Jeroen T. Vermeulen wrote:
Well, except prepared statements apparently; I'm not sure why they are
an
exception.
When I say within a transaction as opposed to outside a transaction,
I
mean of course an explicit transaction. If you want a prepared
statement
to last throughout the session,
I disagree. Lots of people use prepared statements for all kinds of
different reasons. A large percentage of them do not need or make
use
of explicit transactions. Having to continually rebuild the
statement
would be a hassle. The caching mechanism also seems like extra work
for
I
Jeroen wrote:
Granted, that's probably going to force the issue. I do wonder
though:
one of the arguments in favour of the current semantics is that the
problems can be worked around using nested transactions. Then what
were
people doing before nested transactions, in Tom's scenario where
Oliver wrote:
If PREPAREd statements did DEALLOCATE on transaction rollback, the
driver would have to track the set of statements that were first
PREPAREd in the current transaction so it can fix the state on the
driver side if the transaction rolls back. This is a lot of extra
complexity for
I would be fine with changing the lifetime if an EXECUTE failure did
not
abort the current transaction. Then I could simply watch the return
code of the statement execution and prepare the statement on
demand...from my point of view, this would actually be the most
elegant
scenario.
Tom,
I'd accept a mechanism to enforce a timeout at the lock level if you
could show me a convincing use-case for lock timeouts instead of
statement timeouts, but I don't believe there is one. I think this
proposal is a solution in search of a problem.
Hmmm ... didn't we argue this
In phpPgAdmin, I need to know if the backend supports tablespaces or
not. What is the most reliable way of detecting that the backend is
the
win32 native version and hence does not support tablespaces? Version
string info?
Or alternatively, what is the most direct way of detecting its
Does the win32 build have a pg_tablespace table? are there any rows in
it?
Was thinking the combination of the two queries would be able to
determine table space support in some fashion:
select * from pg_class where relnamespace = (select oid from
pg_namespace where nspname =
Jeroen wrote:
I see how making PREPARE obey rollbacks would be inconvenient for some
existing code, but frankly I'm getting a bit worried about the why
should
I care whether what I do is committed or not? argument. I guess one
could
say that about lots of statements: I don't really want this
The big picture here is that with the current behavior, it is
possible
to keep track of existence of prepared statements without wrapping
or
even being aware of transaction activity. This is tremendously
useful
for handling them in a generic way because transactions and prepared
Right now, I'm transitioning to ExexPrepared to skip the string
escaping
step on the client side. I would hate to lose that ability.
ExecParams
is a little more work to set up (doable, though).
OTOH, if you're taking client code queries and replacing them with
EXECUTEs (which I sort of
If we change the syntax, say by using SUBCOMMIT/SUBABORT for
subtransactions, then using a simple ABORT would abort the whole
transaction tree.
Question: with the new syntax, would issuing a BEGIN inside a already
started transaction result in an error?
My concern is about say, a pl/pgsql
Right now subtrans.c is not compiling. SlruCtlData is missing the
'locks'
member in slru.h.
Whoops, I see what happened...never mind (sorry).
Merlin
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
Right now subtrans.c is not compiling. SlruCtlData is missing the
'locks' member in slru.h.
Merlin
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
tom lane wrote:
The bottom line to my mind is that if there were a one-size-fits-all
authentication solution, we'd not have so many to choose from. I
don't
think we are doing DBAs any service by pretending that they might not
need to think about their choice of auth method. I could make a
I noticed a curious thing (not sure if by design or not).
While using the PQExecPrepared interface, the statement name passed to
the function (as a const char*) has to be in lower case to get it to
work. I kind of understand why this is, but it is kind of weird that
passing the exact same
Peter Eisentraut wrote:
Merlin Moncure wrote:
While using the PQExecPrepared interface, the statement name passed
to the function (as a const char*) has to be in lower case to get it
to work. I kind of understand why this is, but it is kind of weird
that passing the exact same statement
There is one problem with the optimizer that is a constant source of
frustration. When using prepared statements and functions (particularly
where function parameters are passed to a query), the optimizer often
fails to utilize an index inside a plan.
This is a well known problem because the
1 - 100 of 1941 matches
Mail list logo
