I've been starting to look at assigning SQLSTATE values to all the
backend elog() calls, and have realized that the set of values defined
by the spec is very, how you say, uneven. They have conditions as
specific as data exception/invalid time zone displacement value
(22009) and yet nothing for
extensions. Anyone have lists of implementation-defined SQLSTATEs for
the big commercial DBs?
http://www-3.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/document.d2w/report?fn=db2m0db2m002.htm#ToC
Chapter 12 has SQLState information. It's very short in most cases
(aside from
Tom Lane wrote:
What do other DBMSes do about this? Seems like it would make sense to
borrow as many SQLSTATE codes as we can from Oracle or DB2 or some other
big player ... especially if there's any commonality in their
extensions. Anyone have lists of implementation-defined SQLSTATEs for
the
Joe Conway [EMAIL PROTECTED] writes:
Tom Lane wrote:
Anyone have lists of implementation-defined SQLSTATEs for
the big commercial DBs?
Does this help?
http://www.csis.gvsu.edu/GeneralInfo/Oracle/appdev.920/a97269/pc_09err.htm#3174
Some, but the mapping table is mostly pretty vague --- for
Now that expressions can be used in indexes in 7.4 you can have multicolumn
indexes that are ordered in different directions. However the planner
doesn't seem to understand that order by -col asc is the same as order by
col desc (for at least the normal -) so you have to be careful how you
write
Hello,
Is there interest to storing and indexed access methods for xml in
postgresql ? While I don't use xml in my applications but I see
possible directions to develop contrib module with indexed access methods
to xml-like data type. We have already contrib/ltree for tree-like
structures and
On Fri, 30 May 2003, Tom Lane wrote:
What do other DBMSes do about this? Seems like it would make sense to
borrow as many SQLSTATE codes as we can from Oracle or DB2 or some other
big player ... especially if there's any commonality in their
extensions. Anyone have lists of
Bruno Wolff III [EMAIL PROTECTED] writes:
Now that expressions can be used in indexes in 7.4 you can have multicolumn
indexes that are ordered in different directions. However the planner
doesn't seem to understand that order by -col asc is the same as order by
col desc (for at least the
On Fri, 30 May 2003, Bruno Wolff III wrote:
Now that expressions can be used in indexes in 7.4 you can have multicolumn
indexes that are ordered in different directions. However the planner
doesn't seem to understand that order by -col asc is the same as order by
col desc (for at least the
http://www.infoworld.com/article/03/05/23/21OPconnection_1.html?platforms
My favorite line from the article is, In last week's column, I
provided an obligatory tease for PostgresSQL in my discussion of
MySQL. A deeper examination of PostgresSQL suggests that it could be
vastly under-hyped.
On Fri, May 30, 2003 at 10:42:24 -0700,
Stephan Szabo [EMAIL PROTECTED] wrote:
On Fri, 30 May 2003, Bruno Wolff III wrote:
Now that expressions can be used in indexes in 7.4 you can have multicolumn
indexes that are ordered in different directions. However the planner
doesn't seem to
Hello everybody,
we've developed a function which reads a huge amount
of data from postgres and, being recursive, does
several memory-intensive elaborations and writes the
results back on two postgres tables. No memory context
switch has been done in our function.
Now we have to compare this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Is there interest to storing and indexed access methods for xml in postgresql?
There is definitely interest. See all the chatter created by my psql-xml patch
on patches/hackers for example. If I get some free time this summer I am going
to look
On Fri, 30 May 2003, Bruno Wolff III wrote:
On Fri, May 30, 2003 at 10:42:24 -0700,
Stephan Szabo [EMAIL PROTECTED] wrote:
On Fri, 30 May 2003, Bruno Wolff III wrote:
Now that expressions can be used in indexes in 7.4 you can have multicolumn
indexes that are ordered in different
On Fri, May 30, 2003 at 11:31:23 -0700,
Stephan Szabo [EMAIL PROTECTED] wrote:
On Fri, 30 May 2003, Bruno Wolff III wrote:
I was hoping the new stuff Tom added would make doing this easier. The issue
has come up before and at least at that time it didn't get changed so I
expected it
Tom Lane writes:
I've been starting to look at assigning SQLSTATE values to all the
backend elog() calls, and have realized that the set of values defined
by the spec is very, how you say, uneven. They have conditions as
specific as data exception/invalid time zone displacement value
=?iso-8859-1?q?Alice=20Lottini?= [EMAIL PROTECTED] writes:
As far as we know, this could be due to the limited
size of the TopMemoryContext in which the dynamically
loadable modules work.
TopMemoryContext is just as expansible as any other context. I'm not
sure what your problem is, but I am
Peter Eisentraut [EMAIL PROTECTED] writes:
In my mind, distinct error codes are only useful if the application can
react differently to the condition.
Agreed, we do not want to divide the error codes too finely. However,
we had a request on the lists just today for an error-code-based way to
I know there are alot of people that really appreciate PG and all the work
that
so many people have contributed. I am also sure that there are alot of
people
who would like to contribute to PG but don't feel they have any means except
in the evangelism arena.
This is something you could
Bruno Wolff III [EMAIL PROTECTED] writes:
I went back and reread the stuff on NEGATOR and found it only applies
to operators that return boolean types. I had thought it was different
and would let you make the deduction a b = -a = -b, but that isn't
the case. Instead it lets you make the
Anyone have lists of implementation-defined SQLSTATEs for
the big commercial DBs?
This points to the Oracle docs.
http://download-west.oracle.com/docs/cd/B10501_01/appdev.920/a87540/ch2.htm
Table 2-2 SQLSTATE Status Codes
---(end of
I was wondering if anyone has had occasion to hook up a compression scheme
(Huffman/gzip/zlib/whatever) as a PostgreSQL function.
I've got a case where there is a need to store fairly large chunks of XML in a
database. There seems little reason to parse it beforehand, as many seem wont
to do.
Gavin Sherry wrote:
Hi all,
There are various places in the backend, such as FreeFile(), where the
return value of fclose() is not tested. Whilst we would often notice any
problems with writing to data files due to testing on fsync(), it could
affect things like COPY ... TO,
On Fri, 30 May 2003, Bruce Momjian wrote:
Gavin Sherry wrote:
Hi all,
There are various places in the backend, such as FreeFile(), where the
return value of fclose() is not tested. Whilst we would often notice any
problems with writing to data files due to testing on fsync(), it could
You are going to love the answer to this question --- it already does
compression of any long fields when it is stored in the TOAST table.
In fact, you have to turn off compression if you don't want it using
ALTER TABLE ... SET STORAGE.
Bruce Momjian [EMAIL PROTECTED] writes:
Gavin Sherry wrote:
There are various places in the backend, such as FreeFile(), where the
return value of fclose() is not tested.
We are not checking fclose, probably because fclose failures are quite
rare. Should we be concerned?
Probably. Closing
Has the single-byte LIKE penalty been eliminated, so we don't need to
consider using C as the default locale for initdb, right?
If fixed, how was it done?
---
Peter Eisentraut wrote:
Tom Lane writes:
I recall someone
Bruce Momjian [EMAIL PROTECTED] writes:
Has the single-byte LIKE penalty been eliminated, so we don't need to
consider using C as the default locale for initdb, right?
I'm still of the opinion that we should make C the default locale.
But I'm not sure where the consensus is, so I've not made
Hello. I thought I'd just toss out a few thoughts:
1) Should a link to the release changes for 7.3.3 be on the website? I
had to look into the web-interface of CVS to see what was actually
changed.
2) It would be nice if some regular performance tests could be done
upon every release on some
On Fri, 30 May 2003, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Gavin Sherry wrote:
There are various places in the backend, such as FreeFile(), where the
return value of fclose() is not tested.
We are not checking fclose, probably because fclose failures are quite
rare.
Tom Lane writes:
Peter has provided a hack whereby one can create a LIKE-supporting index
in a non-C locale. But a *default* index in a non-C locale is still not
going to support LIKE ... and the hacked index will not support ordinary
comparison or ordering operators. So I think there's
I'm not sure that this is the right list to ask - but after having googled a
while it seems that the only ones that might be able to answer this question
is the developers. Therefor, here we go:
As far as I have understood, postgres is autocommiting each typed statement
UNLESS the user
33 matches
Mail list logo
