hello,
I have read the source code of postgres.c. Two strang things I can't understand.
Souce code of Postgres.c:
..
Foreach(parsetree_listparsetree){ //In what situation here will be many
parsetrees
(List *)querytree_list = pg_analyze_and_rewrite(parsetree);
Sorry, no idea. Peter's idea is that FOR UPDATE requires SENSITIVE, so
INSENSITIVE has to be READONLY because the update has to see other
changes to be accurate.
I think clearly SENSITIVE/READONLY should be possible, so:
READONLY/SENSITIVE possible
READONLY/INSENSITIVE
Karel,
IMHO nobody use it -- maybe we can keep it in sources for 7.4 and
mark it in docs as deprecated and remove it in 7.5.
This seems to be consistent with my informal survey on PGSQL-SQL and on
#postgresql. Nobody seems to be using the current behavior.
The date/time and numbers
--On Wednesday, March 26, 2003 08:38:58 -0800 Josh Berkus
[EMAIL PROTECTED] wrote:
Karel,
IMHO nobody use it -- maybe we can keep it in sources for 7.4 and
mark it in docs as deprecated and remove it in 7.5.
This seems to be consistent with my informal survey on PGSQL-SQL and on
#
Larry,
I had a need that should(!) be in the archives. Just to reiterate my need:
I input a contract length, in months, and wanted to get it back out as
months. There is no current way to do this, so I store it as an INT and
concatenate the word months to do the
date arithmetic.
What
--On Wednesday, March 26, 2003 08:50:36 -0800 Josh Berkus
[EMAIL PROTECTED] wrote:
Larry,
I had a need that should(!) be in the archives. Just to reiterate my
need:
I input a contract length, in months, and wanted to get it back out as
months. There is no current way to do this, so I store
Bruce Momjian [EMAIL PROTECTED] writes:
How about sending an INFO or special taged message to the client when
there is a GUC change, and have report_changes as a GUC variable that
controls it?
just brainstorming. But if you're changing the on-wire representation, perhaps
every transaction
Steve Wolfe [EMAIL PROTECTED] writes:
Some time ago, I presented a problem I was having and receiving ERROR:
heap_mark4update: (am)invalid tid on the PG mailing list, and you had
indicated that you'd need access to a machine with a copy of the data so
that you could debg it. I've finally
Bruce Momjian [EMAIL PROTECTED] writes:
How about sending an INFO or special taged message to the client when
there is a GUC change, and have report_changes as a GUC variable that
controls it?
Having such a variable would break the client libraries that need the
information. They won't stop
Tom Lane wrote:
I'm not convinced that it's worth the trouble to make the set of
reported variables be configurable on-the-fly as Bruce was suggesting.
client_encoding and datestyle are candidates to send this way, but are
there really others?
Well, let's look at this from a long term
hi,Bruce Momjian
I think you are wrong. multiple query in a string, such as SELECT;SELECT
will invoke pg_execute_query_string twice, It won't generate two parsetree.
=== 2003-03-26 10:20:00 ===
Jinqiang Han wrote:
hello,
I have read the source code of postgres.c.
Martha Stewart called it a Good Thing whenGary Hendricks [EMAIL PROTECTED]wrote:
I'm thinking of buying Practical PostgreSQL
from O'Reilly.
Has anyone got any comments on this book? Can anyone suggest
alternatives?
My level is best described as intermediate.
Thanks in advance!
The main
Hi
I'm thinking of buying Practical PostgreSQL
from O'Reilly.
Has anyone got any comments on this book?
Can anyone suggest alternatives?
My level is best described as intermediate.
Thanks in advance!
---(end of broadcast)---
TIP 2: you can get
After experiencing so many problems with 7.3.2, I decided to test
7.4-snapshot. It failed only on one test, instead of 17.
NetBSD-1.6 / Alpha (64-bit)
Postgresql-7.4-snapshot-2003-03-24
The error I'm getting is:
! ERROR: datumGetSize: Invalid typLen 0
That error caused many problems in
I just tested this on 7.4-snapshot-2003-03-24 and the same error occurred.
The one regression test (opr_sanity) in 7.4-snapshot that failed also had
this error.
ERROR: datumGetSize: Invalid typLen 0
System: NetBSD / Alpha 1.6 (64 bit)
Postgresql 7.3.2
Bug: after vacuum analyze, I'm unable
Please also note that if you change the data type from text to int, then
the test succeeds:
CREATE TABLE wow_cfgmap (
ts_id int
);
insert into wow_cfgmap values (1);
insert into wow_cfgmap values (2);
CREATE TABLE wow_cfg (
ts_id int
);
insert into wow_cfg values (1);
select
On Wed, 2003-03-26 at 20:42, Thomas T. Thai wrote:
[...]
ERROR: datumGetSize: Invalid typLen 0
Works for me:
[nconway:/home/nconway]% psql -f bug.sql
CREATE TABLE
INSERT 287424 1
INSERT 287425 1
CREATE TABLE
INSERT 287431 1
ts_name | ts_name
-+-
default | default
On Wed, 2003-03-26 at 20:42, Thomas T. Thai wrote:
[...]
ERROR: datumGetSize: Invalid typLen 0
Works for me:
[nconway:/home/nconway]% psql -f bug.sql
CREATE TABLE
INSERT 287424 1
INSERT 287425 1
CREATE TABLE
INSERT 287431 1
ts_name | ts_name
-+-
default | default
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
INSERT INTO table SELECT 1, 'foo' EXCEPT SELECT 1, 'foo' FROM table WHERE
pkcol=1;
See? So now that INSERT statement will insert the row if it doesn't exist,
or insert zero rows if it does. You are then guaranteed that your
transaction will
Uh, why exactly do you think this is race-free?
It looks fancy, but AFAICS the SELECT will return info that is correct
as of its starting timestamp; which is not enough to guarantee that the
INSERT won't conflict with another transaction doing the same thing
concurrently.
How about:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Uh, why exactly do you think this is race-free?
How about:
INSERT INTO table SELECT 1, 'foo' WHERE NOT EXISTS (SELECT TRUE FROM table
WHERE pkcol=1 FOR UPDATE);
It's a lot more straightforward and has a FOR UPDATE. Can this still cause
21 matches
Mail list logo
