Rod Taylor [EMAIL PROTECTED] writes:
Might get somewhere by making a special domain thats marked as being
serial, and using that in the column.
I recall some discussion last year about making serial et al. into
domains over int4 and int8, rather than their current utter-hack
implementation.
On Tue, 2003-03-04 at 19:14, Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
Might get somewhere by making a special domain thats marked as being
serial, and using that in the column.
I recall some discussion last year about making serial et al. into
domains over int4 and int8,
Why not just run PostgreSQL like everyone else does (from a hard drive) and
simply give it heaps of buffers - let PostgreSQL manage its RAM itself?
Unless you have your xlog on physical storage, you are asking for trouble.
Actually, unless you have all your database in physical storage, you are
We are developing a Win32 port of PostgreSQL 7.3(different from Jan's
implementaion, in that we are using a thread model. In the future I
hope we could contribute the source code). We have done a power
failure testing using the test tool made by Dave Page:
Subject: [HACKERS] Win32 Powerfail
* [EMAIL PROTECTED] [EMAIL PROTECTED] [2003-03-04 14:21]:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The XML standard does not call for any table format. But a
number of table formats have been established within the XML
framework. Some of them are formatting-oriented (e.g., the
Eric D Nielsen [EMAIL PROTECTED] writes:
The one place I haven't been able to use PostGreSQL to experiment is with
regards to updateable views. I've found a few threads in -general and -hackers
(including one linked from the ToDo list), but they all seem to die out without
really reaching any
On Tue, 2003-03-04 at 15:26, Eric D Nielsen wrote:
The one place I haven't been able to use PostGreSQL to experiment is with
regards to updateable views. I've found a few threads in -general and -hackers
(including one linked from the ToDo list), but they all seem to die out without
really
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.
Neil Conway [EMAIL PROTECTED] writes:
On Tue, 2003-03-04 at 15:26, Eric D Nielsen wrote:
The one place I haven't been able to use PostGreSQL to experiment is with
regards to updateable views. I've found a few threads in -general and -hackers
(including one linked from the ToDo list), but
I would like to see PostgreSQL eventually support XQuery:
http://www.w3.org/TR/xquery/
http://www.w3.org/TR/query-datamodel/
I see potentially an alternative front end called xsql, providing
substantially the same functionality as psql, only using XQuery syntax and
optionally returning
[EMAIL PROTECTED] writes:
What about a variable that allowed the codes to be switched on so a
number is returned instead of a string? This would be off by default
so as not to break existing applications. Similarly, we can return
other information (FILE, LINE, etc.) with different
On Tue, 2003-03-04 at 15:26, Eric D Nielsen wrote:
The one place I haven't been able to use PostGreSQL to experiment is with
regards to updateable views. I've found a few threads in -general and -hac
kers
(including one linked from the ToDo list), but they all seem to die out wit
hout
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The *last* thing we need is a half-baked stopgap solution that we'll
have to be backwards-compatible with forevermore. Fix it right or
don't do it at all, is MHO.
I agree.
There is still barely enough time to do the long-threatened protocol
This is just about a total conversion of the backend to an xml document
server. The marriage of xml and sql is awkward and not easily
retrofitted to existing databases.
Its pretty much proven that hierarchal storage techniques (xml included)
are more difficult to manage and use than traditional
Gavin Sherry [EMAIL PROTECTED] writes:
I haven't had time to look into it further, but it occurs to me that
handling views which rely on joins would be far from trivial.
Views containing joins would not be updatable; problem solved. The set
of views the automatic-rule-generation machinery
Gavin Sherry [EMAIL PROTECTED] writes:
I haven't had time to look into it further, but it occurs to me that
handling views which rely on joins would be far from trivial.
Views containing joins would not be updatable; problem solved.
I see how that is what the spec says, but aren't the
Eric D Nielsen [EMAIL PROTECTED] writes:
In either case is this a place where exceeding the spec would be a good
thing or a bad thing?
Unless there is an obvious definition of what updating a join means
(obvious not only to the implementor, but to the user) I think this
is dangerous territory.
I've done a lot with XML lately, so I'll throw in my $0.02 worth.
One thing I have noticed about the schemes that are being advanced is that
they seem to be inherently unspecifiable, formally, because column names are
being used as tags.
An alternative might look something like this:
?xml
On Tue, Mar 04, 2003 at 11:04:03PM -0500, Tom Lane wrote:
There is still barely enough time to do the long-threatened protocol
revision for 7.4, if we suck it up and get started on that now. I've
been avoiding the issue myself, because it seems generally boring and
thankless work, but maybe
mlw wrote:
I had written a piece of code about two years ago that used the
aggregate feature of PostgreSQL to create an array of integers from an
aggregate, as:
select int_array_aggregate( column ) from table group by column
While it seems pointless to create an array on a select, it has a
Peter Eisentraut [EMAIL PROTECTED] writes:
Is the so-called debug TTY functionality that you can set in libpq in
various ways still existing? I can't seem to activate it and the code
doesn't show much reference to it.
(a) I believe the TTY option is disabled in the normal postmaster
context,
[EMAIL PROTECTED] writes:
I think all psql needs is a simple output, similar to the ones used by
Oracle, Sybase, and MySQL; the calling application should then process
it in some way as needed (obviously this is not for interactive use).
Where can one find a standard table model?
I think for
Andrew Dunstan writes:
One thing I have noticed about the schemes that are being advanced is that
they seem to be inherently unspecifiable, formally, because column names are
being used as tags.
The SQL/XML draft addresses this by specifying that a mapping from SQL
things to XML things spits
Bob Calco writes:
I would like to see PostgreSQL eventually support XQuery:
The specification is here:
ftp://sqlstandards.org/SC32/WG3/Progression_Documents/FCD/4FCD1-14-XML-2002-03.txt
Go for it.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of
There are Windows binaries on the PostgreSQL FTP server mirrors, for
example,
http://ftp.de.postgresql.org/mirror/postgresql/binary/v7.3.1/Windows/
that users are having problems with. Apparently there is no name or
address of any creator available. So who did this and would like to fix
the
Justin put them up, but I believe that any bug reports for them should be
sent to [EMAIL PROTECTED] ...
On Wed, 5 Mar 2003, Peter Eisentraut wrote:
There are Windows binaries on the PostgreSQL FTP server mirrors, for
example,
Thanks, Merlin, for your thoughtful comments. There is no question that the
marriage of XML and SQL is wrought with semantic difficulties. I'm not sure
the win is compelling enough to justify re-writing the PostgreSQL back end;
on the other hand, it is a juicy technical challenge!
I like
Thanks for the link - I think I just may give it a go. :)
- Bob
%% -Original Message-
%% From: [EMAIL PROTECTED]
%% [mailto:[EMAIL PROTECTED] Behalf Of Peter Eisentraut
%% Sent: Wednesday, March 05, 2003 5:39 PM
%% To: Bob Calco
%% Cc: Merlin Moncure; Alan Gutierrez; [EMAIL PROTECTED]
%%
Peter Eisentraut [EMAIL PROTECTED] writes:
I also think that psql is not the place to implement something like this.
Agreed.
It's most likely best put in the backend, as a function like
xmlfoo('select * from t1;')
That seems a little bizarre. Wouldn't we want to have a switch that
just
I like PostgreSQL just as it is, and truth be told, I'd like to see some
additional features in PL/pgSQL that are completely unrelated to the whole
XML issue. But I see some interesting possibilities for PostgreSQL to make
inroads in enterprise development if it were the first open source
Tom Lane wrote:
This is also a good time to stop and ask whether the frontend/backend
protocol needs to change to support this. Not having read the spec,
I have no idea what the low-level transport needs are for XML output,
but I suspect our present protocol is not it ...
It might be interesting
If it turns out to be that simple, great - my first goal would be not to
touch the backend at all. But I suspect there are some significant semantic
issues lurking in the spec that may make that goal unattainable. In any
event, I agree with the impulse to change nothing in the backend unless
Peter Eisentraut [EMAIL PROTECTED] writes:
I also think that psql is not the place to implement something like this.
Agreed.
It's most likely best put in the backend, as a function like
xmlfoo('select * from t1;')
That seems a little bizarre. Wouldn't we want to have a switch
Hi,
I tried to go buy a shirt off the pgsql.com site, but when it comes to
shipping it just has:
international shipping zone 1
international shipping zone 2
international shipping zone 3
international shipping zone 4
international shipping zone 5
How am I supposed to know which zone Australia
* Merlin Moncure [EMAIL PROTECTED] [2003-03-05 10:02]:
Acually, the difficult part has been getting the information back
into the database. Getting it out is a very simple query. I imagine
that every language/environment has an SQL-XML library somewhere,
but I wasn't able to find
mlw [EMAIL PROTECTED] writes:
I had written a piece of code about two years ago that used the aggregate
feature of PostgreSQL to create an array of integers from an aggregate, as:
select int_array_aggregate( column ) from table group by column
I found this and am using it extensively. It's
Just a reminder on the purpose of the core group --- it is to handle
items that require confidentiality, like confidential discussions with
companies and for discipline.
Marc wants the core group to do as little as possible, so that almost
all activity is done in the open, and the other core
FYI, my contract with SRA has been renewed for another year, meaning I
will continue the next year working on PostgreSQL full time.
I want to thank SRA for their support of the PostgreSQL effort by
employing me. As you may know, Tatsuo Ishii also works for SRA full
time and he is a great help
Marc G. Fournier wrote:
Justin put them up, but I believe that any bug reports for them should be
sent to [EMAIL PROTECTED] ...
Yep, that's the first Proof of Concept build, and it *prominently* has
a message at the start of the installation that says to email me with
any problems about it.
I'm
Tatsuo Ishii wrote:
Sorry, but it does not help. The page says we could use
FlushFileBuffers() to sync the kernel buffer to the
disk. Unfortunately, it requires a file descriptor to flush for its
argument. Thus it could not be a replacement of sync(). Actually I
have modified the buffer
It would be nice if PGAvd could receive row level stats without a large
hit to simple queries.
Ran a simple test. Calling pgstat_report_tabstat() at a frequency of
once per second reduces the time taken for row level stats to be
negligible:
500k select TRUE statements took:
6:50 with stats off
* Merlin Moncure [EMAIL PROTECTED] [2003-03-05 10:03]:
This is just about a total conversion of the backend to an xml document
server. The marriage of xml and sql is awkward and not easily
retrofitted to existing databases.
Its pretty much proven that hierarchal storage techniques (xml
Rod Taylor [EMAIL PROTECTED] writes:
[ optimizing for small frequent queries ]
What if the client doesn't come back with another query for awhile?
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe
Hi guys,
Feels like we've been isolating a whole bunch of bugs in 7.3.2 recently,
some of which are causing crashes out in the real world.
Wondering when we feel it'd be good to start assembling a 7.3.3? I'm
thinking in about two weeks or so, to give a bit more time to catch bugs
and stuff.
Feels like we've been isolating a whole bunch of bugs in 7.3.2 recently,
some of which are causing crashes out in the real world.
Wondering when we feel it'd be good to start assembling a 7.3.3? I'm
thinking in about two weeks or so, to give a bit more time to catch bugs
and stuff.
I
Christopher Kings-Lynne wrote:
I want to fix this bug, however I can't see how the example below is
failing... (Obeys dropped columns) I'm not up with my SRFs, so would
someone be able to post a concise SQL script that demonstrates the failure?
I can see in the code that it should be failing,
Christopher Kings-Lynne wrote:
I want to fix this bug, however I can't see how the example below is
failing... (Obeys dropped columns) I'm not up with my SRFs, so would
someone be able to post a concise SQL script that demonstrates the failure?
I can see in the code that it should be failing,
Joe Conway [EMAIL PROTECTED] writes:
Taking it a bit further...
There are (at least) two distinct problems involved here. One is
getting plpgsql to deal correctly with rowtypes that include dropped
columns. The other is getting it to react when someone alters a table
whose rowtype is relied on
I am back from China and Japan. Most of my visitations were private,
but I did speak at Renmin University in China.
I will catch up on my email in the next few days.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If
While I can see a subquery in UPDATE as working in most cases:
UPDATE tab
SET col - t.col
FROM (SELECT col from xx) AS t
WHERE ...
but I don't see that working for correlated subqueries, where you want
to set a column based on a value you are updating. (Many use
Rod Taylor [EMAIL PROTECTED] writes:
200N spec proposes 'NEXT VALUE FOR sequence'.
Tom will shoot me if I submit that though (VALUE as a keyword again). I
suppose one could make it a variable, and confirm it's value is VALUE?
Anyway, once again we could extend to include:
NEXT VALUE ON
Is this to be applied to CVS? My guess is no.
---
Teodor Sigaev wrote:
Changes:
1 Fixed compile problem on Solaris
2 Add search by weight of lexem.
Readme:
On Wed, 2003-03-05 at 10:36, Bruce Momjian wrote:
Ewe. There would no longer be a guaranteed name for the serial column
sequence. Of course, pg_depend has the information, but how do you get
at that when you create the dump file, and be _sure_ you are going to
hit the right name, especially
On Wed, 5 Mar 2003, Dave Page wrote:
-Original Message-
From: Tatsuo Ishii [mailto:[EMAIL PROTECTED]
Sent: 05 March 2003 02:23
To: [EMAIL PROTECTED]
Subject: [HACKERS] Win32 Powerfail testing
So far we found interesting facts. Our Win32 port passes his
test in most
On Wed, 5 Mar 2003, Bruce Momjian wrote:
Is this to be applied to CVS? My guess is no.
me too. I think we could submit new version after we'll have
documentation.
---
Teodor Sigaev wrote:
Changes:
1 Fixed
Ewe. There would no longer be a guaranteed name for the serial column
sequence. Of course, pg_depend has the information, but how do you get
at that when you create the dump file, and be _sure_ you are going to
hit the right name, especially if you restore only part of the dump.
Seems this
Interesting idea. The bigger problem is that apps who use the sequence
name also would have problems running after the restore. Seems we need
column.nextval() so you can increment the sequence without knowing the
sequence name, just the column name. Of course, this related to this
TODO item:
On Wed, 2003-03-05 at 14:37, Bruce Momjian wrote:
Interesting idea. The bigger problem is that apps who use the sequence
name also would have problems running after the restore. Seems we need
column.nextval() so you can increment the sequence without knowing the
sequence name, just the
Yes, our sequence name/column linkage should be much more automatic than
it is now, and if we do that, we can start to think about sequence name
collision avoidance.
---
Rod Taylor wrote:
-- Start of PGP signed section.
On
I think we should stick with the existing naming convention. The only
actual problem that's been pointed out here is that an ALTER TABLE
(or COLUMN) RENAME on a serial column doesn't update the sequence name
to match. Seems to me we could fix that with less effort than any of
these
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
I think we should stick with the existing naming convention.
^^
Non-colliding?
No; see above.
Otherwise, it'd be ludicrous to fail a table rename because
a sequence with the new
I want to fix this bug, however I can't see how the example below is
failing... (Obeys dropped columns) I'm not up with my SRFs, so would
someone be able to post a concise SQL script that demonstrates the failure?
I can see in the code that it should be failing, but I need a demonstrated
Added to TODO:
o Have ALTER TABLE rename SERIAL sequences
Seems we at least need this. Doesn't dependency tracking make this
easy to do now?
---
Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
63 matches
Mail list logo
