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 remembe
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
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
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 stoc
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
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 someo
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.
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.
---
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()
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, CreateOpts
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.
>> 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 broadcast)-
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
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 probably
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 t
=?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
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"
>
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
> > expect
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
-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
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 func
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 s
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. Histor
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
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, 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 implementatio
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 rece
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 qu
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 -
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 bi
> 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 'Warn
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
33 matches
Mail list logo
