Greg Copeland wrote:
At this point in time, I think we've both pretty well beat this topic
up. Obviously there are two primary ways of viewing the situation. I
don't think anyone is saying it's a bad idea...I think everyone is
saying that it's easier to address elsewhere and that overall,
Can someone who is multbyte-aware comment on this patch? Thanks.
---
Manuel Sugawara wrote:
Attached is a pacth against 7.2 which adds locale awareness to
the character classes of the regular expression engine. Please
Bruce Momjian [EMAIL PROTECTED] writes:
Also, on the NOTIFY/trigger idea, triggers are called on statement end,
not transaction end, so if an UPDATE query is in a multi-statement
transaction, another backend looking for the NOTIFY will receive it
before the transaction commits, meaning it
Barry Lind [EMAIL PROTECTED] writes:
In testing Neil's PREPARE/EXECUTE patch on my test query, I found the
parser complains that this query is not valid when using current
sources. The error I get is:
psql:testorig.sql:1: ERROR: JOIN/ON clause refers to xf2, which is
not part of JOIN
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Also, on the NOTIFY/trigger idea, triggers are called on statement end,
not transaction end, so if an UPDATE query is in a multi-statement
transaction, another backend looking for the NOTIFY will receive it
before the transaction
Bruce Momjian [EMAIL PROTECTED] writes:
No it won't.
Is this because NOTIFY is held for transaction end or because the
triggers are held until transaction commit?
The former.
regards, tom lane
---(end of broadcast)---
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
No it won't.
Is this because NOTIFY is held for transaction end or because the
triggers are held until transaction commit?
The former.
Thanks. I see it in the NOTIFY manual page now. Very nice.
--
Bruce Momjian
On Sun, 14 Apr 2002, Bruce Momjian wrote:
Gavin, I will do the legwork on this if you wish. I think we need to
No matter. I intended to submit a patch to fix this.
use DefElem to store the COPY params, rather than using specific fields
in CopyStmt.
DefElem would have required
Gavin Sherry writes:
The patch attached maintains backward compatibility. The syntax is as
follows:
COPY [BINARY] relname [WITH OIDS] FROM/TO
[USING DELIMITERS delimiter]
[WITH [ DELIMITER delimiter | NULL AS char | OIDS ]]
I think we should lose the WITH
[Trimmed CC list]
On Sunday 14 April 2002 01:52 am, Hannu Krosing wrote:
On Sun, 2002-04-14 at 08:48, Lamar Owen wrote:
Incidentally, the 7.2.93 (skipjack) public beta is a serious improvement
over RHL 7.2, and I personally recommend it, as KDE 3 is worth the
upgrade, even to a beta.
Is
On Sunday 14 April 2002 03:00 pm, Luciano Miguel Ferreira Rocha wrote:
On Sun, Apr 14, 2002 at 02:35:13PM -0400, Lamar Owen wrote:
Raw performance seems to be increased as well, due to an improved kernel
(2.4.18 plus low-latency and preemptible patches, according to the kernel
source RPM).
Gavin, I see where you are going with the patch; creating a list in
gram.y and stuffing CopyStmt directly there. However, I can't find any
other instance of our stuffing things like that in gram.y. We do have
cases using options like COPY in CREATE USER, and we do use DefElem.
I realize it
On Sun, Apr 14, 2002 at 03:15:39PM -0400, Lamar Owen wrote:
ISTM that improving interactive performance would also improve multiuser
performance in a server, as low latency and kernel preemption can increase
multiuser server responsiveness.
I doubt any performance will increase, either on a
On Fri, Apr 12, 2002 at 12:51:26PM -0400, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Certainly a shared cache would be good for apps that connect to issue a
single query frequently. In such cases, there would be no local cache
to use.
We have enough other problems with the
On Sat, Apr 13, 2002 at 06:47:32PM -0400, Neil Conway wrote:
I've attached an updated version of Karel Zak's pg_qcache patch, which
adds PREPARE/EXECUTE support to PostgreSQL (allowing prepared SQL
statements). It should apply cleanly against CVS HEAD, and compile
properly -- beyond that,
I'm not exactly sure what you're touching, but could it wait for the
below pg_depend patch to be either accepted or rejected? It lightly
fiddles with a number of files in the command and catalog directories.
http://archives.postgresql.org/pgsql-patches/2002-04/msg00050.php
That shouldn't be
On Sun, Apr 14, 2002 at 10:13:17PM +0200, Karel Zak wrote:
(2) Sometimes executing a PREPARE gives this warning:
nconway= prepare q1 as select * from pg_class;
WARNING: AllocSetFree: detected write past chunk end in TransactionCommandContext
0x83087ac
PREPARE
Does anyone know
On Sun, 2002-04-14 at 21:30, Rod Taylor wrote:
I'm not exactly sure what you're touching, but could it wait for the
below pg_depend patch to be either accepted or rejected? It lightly
fiddles with a number of files in the command and catalog directories.
Sounds fair. I'd have brought it up earlier but was away last week.
The changes I made are very straight forward and easy enough to redo.
--
Rod Taylor
Your eyes are weary from staring at the CRT. You feel sleepy. Notice
how restful it is to watch the cursor blink. Close your eyes. The
On Sun, 14 Apr 2002 22:39:32 +0200
Karel Zak [EMAIL PROTECTED] wrote:
- PREPARE_KEY_PREFIX_SIZE is 4 not 3
- in the PrepareKey() is needful fix:
+ if (store == PREPARE_STORE_SHARE) { /* shared between same DB */
+ *flag |= QCF_SHARE_NOTREMOVEABLE;
+
On Sun, 2002-04-14 at 21:58, Rod Taylor wrote:
Sounds fair. I'd have brought it up earlier but was away last week.
The changes I made are very straight forward and easy enough to redo.
I've sent the patch to the -patches list -Please let me know if there
are any queries -I will be able to
Here is a patch that implements Tom's suggestion of mallocing the
relation name string as part of PQnotify and not depending on
NAMEDATALEN. Nice trick.
---
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
The
On 13 Apr 2002, Hannu Krosing wrote:
On Fri, 2002-04-12 at 03:04, Brian Bruns wrote:
On 11 Apr 2002, Hannu Krosing wrote:
IIRC someone started work on modularising the network-related parts with
a goal of supporting DRDA (DB2 protocol) and others in future.
That was me, although
With my pg_hba.conf changes done, I am now focusing in the next few days
on clearing out my email/patch application backlog.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830
I'm running into a minor issue with security in regards to users being
able to see constructs that they have no access too.
The solution? Information_Schema coupled with no direct access to
pg_catalog. Internals can use pg_catalog, possibly super users, but
regular users shouldn't be able to
Rod Taylor wrote:
I'm running into a minor issue with security in regards to users being
able to see constructs that they have no access too.
The solution? Information_Schema coupled with no direct access to
pg_catalog. Internals can use pg_catalog, possibly super users, but
regular
Could this get cleaned up please?
make[4]: Entering directory `/home/postgres/pgsql/src/interfaces/ecpg/preproc'
bison -y -d preproc.y
mv -f y.tab.c ./preproc.c
mv -f y.tab.h ./preproc.h
gcc -O1 -Wall -Wmissing-prototypes -Wmissing-declarations -g -Wno-error -I./../include
-I.
Rod Taylor writes:
The solution? Information_Schema coupled with no direct access to
pg_catalog. Internals can use pg_catalog, possibly super users, but
regular users shouldn't be able to do any reads / writes to it
directly -- as per spec with definition_schema.
The catch on this is that
Yes.
A number of people in the company have mentioned that our customers
can see tables and structures which they shouldn't know exist.
Not a severe issue, but it's a checkmark for those wanting to switch
to Oracle.
Revoking read access to system catalogs causes interesting things to
occur :)
On Sun, 14 Apr 2002, Bruce Momjian wrote:
Gavin, I see where you are going with the patch; creating a list in
gram.y and stuffing CopyStmt directly there. However, I can't find any
other instance of our stuffing things like that in gram.y. We do have
cases using options like COPY in
Gavin Sherry wrote:
On Sun, 14 Apr 2002, Bruce Momjian wrote:
Gavin, I see where you are going with the patch; creating a list in
gram.y and stuffing CopyStmt directly there. However, I can't find any
other instance of our stuffing things like that in gram.y. We do have
cases
Yeah, I was planning on blocking queries to pg_catalog for all cases.
Make it so that it can never be done by any user directly. It would
have to be done in the parser before the view was evaluated, and no
user created views would be allowed to access pg_catalog.
The spec describes the
Can someone who is multbyte-aware comment on this patch? Thanks.
I thought the patch is not relevant to multibyte support?
--
Tatsuo Ishii
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send
Peter Eisentraut [EMAIL PROTECTED] writes:
For instance, if you create a view
CREATE VIEW bar AS SELECT * FROM foo;
then the statement
SELECT * FROM bar;
needs privileges to read foo.
This works just fine, thank you: the privileges are checked against the
owner of the view.
The
If Bruce is thinking of applying outstanding patches - whatever happened
with Bill Studenmund's CREATE OPERATOR CLASS patch?
Chris
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Tatsuo Ishii wrote:
Can someone who is multbyte-aware comment on this patch? Thanks.
I thought the patch is not relevant to multibyte support?
Sorry, yes, it is for locale.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610)
Tom Lane wrote:
But having said that, I do not foresee being able to replace direct
pg_catalog access with INFORMATION_SCHEMA views anytime soon. There
are too many clients out there that are used to doing it that way.
Moreover, pg_dump will never be able to work off INFORMATION_SCHEMA,
For the non-spec compliant stuff, I was going to add various pg_ views
to accomodate it, but with the spirit of the spec. That is, users can
only see catalog entries which they have access to, and can only view
definitions of entries that they have ownership of.
Anyway, I got the feedback I
Good question. I see the thread at:
Christopher Kings-Lynne wrote:
Also, it seems to me that at some point we are forced to break client
compatibility.
It's not a users' consensus at all. I'm suspicious if
DROP COLUMN is such a significant feature to break
client compatibility at our ease.
Either we add attisdropped field to
I submitted a patch which would make Postgresql ANSI compliant in
regards to INSERT with a provided column list. As Tom states below,
this is not full compliance.
CREATE TABLE tab(col1 text, col2 text);
INSERT INTO tab (col1, col2) VALUES ('val1'); -- bad by spec (enforced
by patch)
INSERT
[ Discussion moved to hackers.]
We are discussing TODO item:
o Disallow missing columns in INSERT ... VALUES, per ANSI
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Do you want to argue we should continue allowing it?
No; I'm objecting that there hasn't been adequate
Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
CREATE TABLE tab(col1 text, col2 text);
INSERT INTO tab (col1, col2) VALUES ('val1'); -- bad by spec (enforced
by patch)
INSERT INTO tab (col1, col2) VALUES ('val1', 'val2'); -- good
INSERT INTO tab VALUES ('val1'); -- bad by
Rod Taylor wrote:
For the latter one, it could be argued that the user understands the
table in question and has inserted the values they require. New
columns are added at the end, and probably don't affect the operation
in question so why should it be changed to suit new columns? But,
Whatever you do with this patch, remember that the USE_LOCALE symbol is
gone.
Bruce Momjian writes:
Can someone who is multbyte-aware comment on this patch? Thanks.
---
Manuel Sugawara wrote:
Attached is a pacth
On Thu, 11 Apr 2002, Barry Lind wrote:
I'm not sure that JDBC would use this feature directly. When a
PreparableStatement is created in JDBC there is nothing that indicates
how many times this statement is going to be used. Many (most IMHO)
will be used only once.
Well, the particular
Tom,
OK here is a test case:
create table test1 (t1a int);
create table test2 (t2a int);
create table test3 (t3a int);
SELECT x2.t2a
FROM ((test1 t1 LEFT JOIN test2 t2 ON (t1.t1a = t2.t2a)) AS x1
LEFT OUTER JOIN test3 t3 ON (x1.t2a = t3.t3a)) AS x2
WHERE x2.t2a = 1;
The select works under 7.2,
Peter Eisentraut wrote:
Rod Taylor writes:
I submitted a patch which would make Postgresql ANSI compliant in
regards to INSERT with a provided column list. As Tom states below,
this is not full compliance.
CREATE TABLE tab(col1 text, col2 text);
INSERT INTO tab (col1, col2)
Bruce Momjian writes:
Peter, are you saying you don't want to require all columns to be
specified when INSERT doesn't list the columns?
Yes, that's what I'm saying. Too much breakage and annoyance potential in
that change.
--
Peter Eisentraut [EMAIL PROTECTED]
Barry Lind [EMAIL PROTECTED] writes:
OK here is a test case:
Looks like a bug, all right --- I must have introduced this when I redid
the handling of JOIN aliases a few weeks ago. Will fix.
Thanks for the report.
regards, tom lane
---(end of
Peter Eisentraut [EMAIL PROTECTED] writes:
I recall that this was the behavior we agreed we wanted. IMHO, it would
be conditional on the INSERT ... VALUES (DEFAULT) capability being
provided. I'm not sure if that is there yet.
That is there now. Do you recall when this was discussed
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Ruling out this case would break a technique that I've used a lot in the
past, which is to put defaultable columns (eg, SERIAL columns) at the
end, so that they can simply be left out of quick manual inserts.
Yes, I understand the
Rod Taylor [EMAIL PROTECTED] writes:
CREATE TABLE tab(col1 text, col2 text);
INSERT INTO tab (col1, col2) VALUES ('val1'); -- bad by spec (enforced
by patch)
INSERT INTO tab (col1, col2) VALUES ('val1', 'val2'); -- good
INSERT INTO tab VALUES ('val1'); -- bad by spec (not enforced)
INSERT
Curt Sampson wrote:
On Thu, 11 Apr 2002, Barry Lind wrote:
I'm not sure that JDBC would use this feature directly. When a
PreparableStatement is created in JDBC there is nothing that indicates
how many times this statement is going to be used. Many (most IMHO)
will be used only once.
INSERT INTO tab VALUES ('val1'); -- bad by spec (not enforced)
INSERT INTO tab VALUES ('val1', 'val2'); -- good
I recall that this was the behavior we agreed we wanted. IMHO, it
would
be conditional on the INSERT ... VALUES (DEFAULT) capability being
provided. I'm not sure if that is
Rod Taylor writes:
I submitted a patch which would make Postgresql ANSI compliant in
regards to INSERT with a provided column list. As Tom states below,
this is not full compliance.
CREATE TABLE tab(col1 text, col2 text);
INSERT INTO tab (col1, col2) VALUES ('val1'); -- bad by spec
Tom Lane writes:
Peter Eisentraut [EMAIL PROTECTED] writes:
For instance, if you create a view
CREATE VIEW bar AS SELECT * FROM foo;
then the statement
SELECT * FROM bar;
needs privileges to read foo.
This works just fine, thank you: the privileges are checked against the
On Sun, 14 Apr 2002, Barry Lind wrote:
But since the syntax for prepare is: PREPARE name AS statement you
can't easily reuse sql prepared by other PreparedStatement objects since
you don't know if the sql you are about to execute has or has not yet
been prepared or what name was used in
Barry Lind [EMAIL PROTECTED] writes:
The select works under 7.2, but gives the following error in 7.3:
ERROR: JOIN/ON clause refers to x1, which is not part of JOIN
I've committed a fix for this. Thanks again.
regards, tom lane
---(end of
Whatever you do with this patch, remember that the USE_LOCALE symbol is
gone.
I thought we have some way to tern off locale support at the configure
time.
--
Tatsuo Ishii
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
60 matches
Mail list logo
