On Mon, 2005-05-23 at 22:43 -0400, Tom Lane wrote:
> Based on the comments so far in this thread, I'll go ahead and commit
> the patch, with some comments attached of course --- in particular a big
> head comment to run flex with -b and see that lex.backup says something
> to this effect.
flex cou
Dnia 24-05-2005, wto o godzinie 00:06 -0400, Tom Lane napisał(a):
> Joe Conway <[EMAIL PROTECTED]> writes:
> > Markus Bertheau wrote:
> >> why does SELECT ARRAY(SELECT 1 WHERE FALSE) return NULL instead of
> >> ARRAY[] resp. '{}'?
>
> > Why would you expect an empty array instead of a NULL?
>
> I
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> ...
>3) All deadlocks are fighting for the same relation: 4335271, which is
> the tsearch2 fulltext index on the articles table:
> articles_idxft1_idx.
> DETAIL: Process 8122 waits for AccessExclusiveLock on relation 4335271 of
> d
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> However, the lexer isn't touched anywhere near as much as the grammar is
> right?
Yeah --- if you look at the CVS history, changes that affect the flex
rules (and not just the text of the C-code actions) are really rare
these days. If there
Based on the comments so far in this thread, I'll go ahead and commit
the patch, with some comments attached of course --- in particular a big
head comment to run flex with -b and see that lex.backup says something
to this effect.
Add it to the release check-list.
Chris
---
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Mon, 2005-05-23 at 12:31 -0400, Tom Lane wrote:
>> doesn't seem to be any way to get flex to complain if someone later
>> makes a change that breaks the no-backup-cases property again.
> After some digging, there is a -b option will generate a file cal
But I do think it's worth it, even so ... not all client interfaces
support prepared statements (notoriously PHP, although I understand KL
has sent patches to fix that) and not all inserts are suitable for COPY.
There is now pg_prepare/pg_execute/pg_query_params in PHP, however you
could alway
I haven't had much experience (okay, I've yet to use it) with tsearch2,
but according to
http://www.postgresql.org/docs/8.0/interactive/limitations.html, GiST
does have concurrency issues "The current implementation of GiST within
PostgreSQL has some major limitations: GiST access is not concur
What I'm wondering is whether this is really worth doing or not.
There are currently just two parts of the lexer rules that are affected
--- the {real} rule illustrated above, and the rules that allow quoted
strings to be split across lines as the SQL spec requires. But the
patches are still pret
Second part to the other question ... the function/trigger attempts to be
smart ... basically, it checks the updated record to see if there has been
any changes that warrant updating the tsearch2 index, and only does it if
it needs to ...
Apparently, even if there are no changes, the Lock is
Client is running 7.4.6 right now (we're looking at moving to 7.4.8 when
we can get a suitable ops window for the upgrade), and is experiencing
semi-regular (10-16 times a day) deadlocks, with the following
information:
A little background:
1) We do not do explicit row or table locking.
I think you need to test with 5 characters, not 3.
--
Tatsuo Ishii
> Ahemm,...
>
> UNICODE DB:
>
> create table t (a char(10));
> set client_encoding = iso88591;
> insert into t VALUES ('æøå');
>
> select a, octet_length(a),length(a) from t;
> a | octet_length | length
> +
Ahhh...
> -Original Message-
> From: Tatsuo Ishii [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 24, 2005 9:26 AM
> To: John Hansen
> Cc: [EMAIL PROTECTED]; pgsql-patches@postgresql.org;
> pgsql-hackers@postgresql.org
> Subject: Re: [PATCHES] character type value is not padded with spac
Ahemm,...
UNICODE DB:
create table t (a char(10));
set client_encoding = iso88591;
insert into t VALUES ('æøå');
select a, octet_length(a),length(a) from t;
a | octet_length | length
+--+
æøå| 13 | 3
(1 row)
This is with 8.0.2.
Hackers,
The problem he found is not only existing in Japanese characters but
also in any multibyte encodings including UTF-8. For me the patch
looks good and I will commit it to 7.3, 7.4, 8.0 stables and current
if there's no objection.
--
Tatsuo Ishii
> Character type value including multibyte
Hi,
> I modified the TODO. I think we only need an INT4. I realize INT8
> would be for IPV6 but I can't imagine a network that has more than INT4
> hosts (not part of the network address).
Actually "increment the host address" isn't a well-defined concept for
IPV6. The "host" part of the add
Tom Lane wrote:
[snip - flex is slowed down by backtracking - how to fix ]
What I'm wondering is whether this is really worth doing or not.
There are currently just two parts of the lexer rules that are affected
--- the {real} rule illustrated above, and the rules that allow quoted
strings t
On Mon, 2005-05-23 at 12:31 -0400, Tom Lane wrote:
> doesn't seem to be any way to get flex to complain if someone later
> makes a change that breaks the no-backup-cases property again.
After some digging, there is a -b option will generate a file called
lex.backup if any backup-states exist. The
Stef,
> I am trying to write a function/Trigger in pl/perl (although any
> other language which allows this is perfectly fine with me :) and I need to
> find the firing statement. I understand that if the trigger was fired in
> a long sequence, then of course, the calling statement will be the
Hello Everyone,
Apologies in advance, its time for another of my whacky 'can we do
this' emails ;)
I am trying to write a function/Trigger in pl/perl (although any
other language which allows this is perfectly fine with me :) and I need to
find the firing statement. I understand that if th
This seems fine. I don't think the lexer changes enough for us to have
issues with new cases. I think adding some comments to explain why we
are doing it is enough, and perhaps a test case that can be reproduced
later for testing.
I was doing some profiles recently that showed that on simple statements
(like INSERT with a few column values) the basic parser (flex/bison) was
taking up a noticeable percentage of the total CPU time. We already
have done some things to speed up the lexer, like use -CF option for
large-but-fast
* Bruce Momjian (pgman@candle.pha.pa.us) wrote:
> Douglas McNaught wrote:
> > Bruce Momjian writes:
> >
> > > I modified the TODO. I think we only need an INT4. I realize INT8
> > > would be for IPV6 but I can't imagine a network that has more than INT4
> > > hosts (not part of the network addr
Douglas McNaught wrote:
> Bruce Momjian writes:
>
> > I modified the TODO. I think we only need an INT4. I realize INT8
> > would be for IPV6 but I can't imagine a network that has more than INT4
> > hosts (not part of the network address).
>
> Actually "increment the host address" isn't a wel
Bruce Momjian writes:
> I modified the TODO. I think we only need an INT4. I realize INT8
> would be for IPV6 but I can't imagine a network that has more than INT4
> hosts (not part of the network address).
Actually "increment the host address" isn't a well-defined concept for
IPV6. The "host
I have tried using INSTEAD rules but there are some
conditional logic that needs to happen inside the rule
(performing counts, getting and storing the primary
key of the master record etc.). AFAIK, rules only
allows conditional logic to be check prior to
execution of the rule and not inside the ru
Christopher Kings-Lynne wrote:
I have a similar problem and already considered using RULEs, but I
encountered the problem, that I did not find any way to execute
procedures from RULEs without using SELECT, which creates always a
result set being passed to the application invoking the INSERT,
I have a similar problem and already considered using RULEs, but I
encountered the problem, that I did not find any way to execute
procedures from RULEs without using SELECT, which creates always a
result set being passed to the application invoking the INSERT, UPDATE
or DELETE, even if the fun
I have a similar problem and already considered using RULEs, but I
encountered the problem, that I did not find any way to execute
procedures from RULEs without using SELECT, which creates always a
result set being passed to the application invoking the INSERT, UPDATE
or DELETE, even if the fun
You can probably just create an INSTEAD rule on the view...
Chris
--= Tono =-- wrote:
Is there any plans to create an INSTEAD OF trigger on
VIEWS? I have view which consists of a master and
detail table. When a row is inserted into the view,
the view needs to figure out if the master record
Is there any plans to create an INSTEAD OF trigger on
VIEWS? I have view which consists of a master and
detail table. When a row is inserted into the view,
the view needs to figure out if the master record
already exsists. If the record does not exists in the
master table, then insert into the m
Zeljko Vrba wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi! I have posted this as a user comment in section 9.17:
-
= ANY(array expression) doesn't work in the obvious way when the array
expression is a subselect. For example:
select * from stat3 where stat3.id = any ('{4,5,6,7}'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi! I have posted this as a user comment in section 9.17:
-
= ANY(array expression) doesn't work in the obvious way when the array
expression is a subselect. For example:
select * from stat3 where stat3.id = any ('{4,5,6,7}');
works (and return
On Saturday 21 May 2005 03:37, Josh Berkus wrote:
> 2PC is a key to supporting 3rd-party replication tools, like C-JDBC.
I don't think C-JDBC requires 2PC for replication. Mixed up acronyms maybe? :)
--
Jose Orlando Pereira
---(end of broadcast)--
34 matches
Mail list logo
