Patch applied. Thanks.
---
Gregory Stark wrote:
>
> Just some fixups to a couple contrib directories I was trying out.
>
> . replace CREATE OR REPLACE AGGREGATE with a separate DROP and CREATE
> . add DROP for all CREATE
I've been amusing myself the last several evenings by working on a
reimplementation of the NUMERIC datatype, along the lines of previous
discussion (use base-1 digits instead of base-10 so that the number
of iterations of the inner loops decreases by a factor of about 4).
It's not ready to com
On 19 Mar 2003 at 9:20, Josh Berkus wrote:
> Guys,
>
> > You make an astute observation that I think should become a strategy of the
> > advocacy team. That is to portray MySQL as a "hobby" database, but Postgres
> > as a "production" database. I think this is a very easy stance to take,
> > sinc
Alvaro Herrera wrote:
> On Wed, Mar 19, 2003 at 05:45:39PM -0500, Bruce Momjian wrote:
>
> > Here are a list of features that might be in 7.4. I know there are
> > several people involved in each of these items.
>
> I think you forgot error codes and associated stuff.
That is part of the wire p
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Sorry I have a basic question.
> Was there any consensus we would introduce nested transactions
> (or savepoints) in the way currently discussed ?
I think we are a long way from saying we can or will actually do it.
Error handling and resource management
Hiroshi Inoue wrote:
> Bruce Momjian wrote:
> >
> > OK, I have a patch to fix this bug. The basic problem is that when a
> > multi-query string is passed to the backend, it is treated as a single
> > transaction _unless_ a transaction or GUC command appears in the string.
> > When they appear, a
On Wed, Mar 19, 2003 at 05:45:39PM -0500, Bruce Momjian wrote:
> Here are a list of features that might be in 7.4. I know there are
> several people involved in each of these items.
I think you forgot error codes and associated stuff.
--
Alvaro Herrera ()
"Sallah, I said NO camels! That's FIVE
> Anyway, on to MySQL. The had a booth there. I asked their technical guy
> a few questions and he seemed to have a decent understanding. When I
> asked the question, "Why would I choose MySQL over something like
> PostgreSQL?" his response was "There is one company driving MySQL. Also,
> when
On Wed, 19 Mar 2003, Alvaro Herrera wrote:
> On Wed, Mar 19, 2003 at 10:26:05PM +0300, Oleg Bartunov wrote:
>
> > we have a little problem in new version of tsearch we're currently
> > working. We've implemented concatenation operation for txtidx type
> > and treat concatenation with NULL as NULL
On Wednesday 19 March 2003 04:33 am, you wrote:
> Dave Cramer <[EMAIL PROTECTED]> writes:
> > On Tue, 2003-03-18 at 19:00, Hiroshi Inoue wrote:
> >> ODBC(maybe JDBC also) has cross-transaction result sets
> >> (rather than cursors) since long by simply holding all
> >> results for a query at client
Hannu Krosing <[EMAIL PROTECTED]> writes:
> the more accurate (nonstandard) syntax could have been
>
> SELECT src.val,
>tgt.val
> FROM updatesrc as src FOR UPDATE,
>updatetgd as tgt
> WHERE src.id = tgt.id
>SET src.val = tgt.val
> ;
The syntax in Oracle, for example, wou
On 16 Mar 2003, Hannu Krosing wrote:
> Tom Lane kirjutas R, 14.03.2003 kell 19:15:
> > Greg Stark <[EMAIL PROTECTED]> writes:
> > > So, just to throw out a wild idea: If you're talking about making large
> > > changes to the on-the-wire protocol. Have you considered using an existing
> > > databas
mlw, would you modify this to use the config_path idea we agreed upon so
we can get this into 7.4?
---
mlw wrote:
> This is a patch that allows PostgreSQL to use a configuration
> file that is outside the main database direc
To improve handling of autocommit off mode, I am proposing a change in
our next release. Right now, if you pass multiple queries in the same
string to the backend:
psql -c 'INSERT INTO test VALUES (1);INSERT INTO test VALUES (2);" template1
the query is considered to be a single transact
On Wed, 19 Mar 2003 13:00:07 -0500, Tom Lane <[EMAIL PROTECTED]>
wrote:
>Manfred Koizar <[EMAIL PROTECTED]> writes:
>> And if the change is lost, it can
>> be redone by the next backend visiting the tuple.
>
>Not if the subtransaction log state has been removed as no longer
>needed.
But this probl
> I see no concurrency problems. If two or more backends visit the same
> tuple, they either write the same value to the same position which
> doesn't hurt, or one sees the other's changes which is a good thing.
AFAIR, on multi-CPU platforms it's possible that second transaction could
see COMMITT
Manfred Koizar <[EMAIL PROTECTED]> writes:
> If the sequence is "first update xmin, then set the commit bit", we
> never have an inconsistent state. And if the change is lost, it can
> be redone by the next backend visiting the tuple.
Not if the subtransaction log state has been removed as no lon
On Wed, 19 Mar 2003 11:18:38 -0500, Tom Lane <[EMAIL PROTECTED]>
wrote:
>Manfred Koizar <[EMAIL PROTECTED]> writes:
>> If we set XMIN/MAX_IS_COMMITTED in a tuple header, we have to replace
>> a sub-transaction xid in xmin or xmax respectively with the
>> main-transaction xid at the same time. Othe
OK, I have a patch to fix this bug. The basic problem is that when a
multi-query string is passed to the backend, it is treated as a single
transaction _unless_ a transaction or GUC command appears in the string.
When they appear, a transaction is forced, but the normal transaction
state machine
Manfred Koizar <[EMAIL PROTECTED]> writes:
> If we set XMIN/MAX_IS_COMMITTED in a tuple header, we have to replace
> a sub-transaction xid in xmin or xmax respectively with the
> main-transaction xid at the same time. Otherwise we'd have to look
> for the main xid, whenever a tuple is touched.
Th
On Wed, 19 Mar 2003, Shridhar Daithankar<[EMAIL PROTECTED]> wrote:
> Just stumbled upon this. Is it correct to conclude that foreign keys are not
> inherited from this text?
Yes. If you want more info, check out the archives.
---(end of broadcast)---
Tom Lane kirjutas K, 19.03.2003 kell 16:46:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I wasn't sure it made logical sense to allow correlated subqueries in
> > FROM because the FROM is processed before the WHERE.
>
> It doesn't; in fact it violates the whole semantic model of SQL,
> as far as
Hi,
Just stumbled upon this. Is it correct to conclude that foreign keys are not
inherited from this text?
phd=# create table perbookings(type smallint) inherits (bookings);
CREATE TABLE
phd=# \d perbookings;
Table "public.perbookings"
Column |
I'm having a problem with my postgresql email. I cannot access my imap
account on postgresql.org anymore. For two or three days now no mail to
[EMAIL PROTECTED] has made it to me. And I wasn't able to conatct
Marc so far. The account is there as I can login via ssh.
So if you want to contact me, f
Bruce Momjian kirjutas E, 17.03.2003 kell 20:49:
> With no one replying on how to do correlated subqueries in FROM for
> UPDATE,
Correlated subqueries not working in FROM cluse of UPDATE is IMHO a bug,
so the way to do correlated subqueries in FROM for UPDATE would be to
fix this bug ;)
All commo
hello，
what is RIR rules in Rewriter? What RIR means?
Thank you very much.
Jinqiang Han
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
messag
26 matches
Mail list logo
