> 1. Postgres appears to have a fairly high row overhead (40 bytes
> or so according to the FAQ), which grieves me slightly, as that's
> actually larger than the size of the data in my tuples. It would
> seem that in my case some of the items in that header (the OID and
> the NULL bitfield) are no
Appended is a message that I sent to the pgsql-general list, and
for which I received no useful reply. (Well, anyway, no reply that
has helped me to speed up my imports.) If you've read it already,
feel free to ignore it, but if you haven't, I'd appreciate any
advice on how to make this work as f
I have hit another very annouing problem with the oids being larger than
max_int. When tables are created under such circumstances, pg_dump cannot dump
the database anymore. The error is
getTables(): SELECT (for PRIMARY KEY) failed on table config_2002_03_02.
Explanation from backend: ERROR:
> 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
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 o
On Sun, 14 Apr 2002, Barry Lind wrote:
> But since the syntax for prepare is: PREPARE AS 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 was used in that prepare. T
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 checke
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
> > 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 tha
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
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Gavin Sherry wrote:
>> CREATE DATABASE also fills out a list in the same fashion =). I will
>> however have a look at revising this patch to use DefElem later today.
> Oh, I see that now. Which method do people prefer. We should probably
> make them a
"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)
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
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 be
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 o
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]
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 (c
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,
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
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 p
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,
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'
[ 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 adeq
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 INTO
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
Good question. I see the thread at:
http://groups.google.com/groups?hl=en&threadm=Pine.LNX.4.30.0202262002040.685-10%40peter.localdomain&rnum=2&prev=/groups%3Fq%3Dcreate%2Boperator%2Bgroup:comp.databases.postgresql.*%26hl%3Den%26selm%3DPine.LNX.4.30.0202262002040.685-10%2540pet
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 want
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
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)
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
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.
> 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 "u
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. -I../../../../src
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 definitio
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
>
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
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 :)
-
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 t
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
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 do
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 Blyt
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 wa
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:
> > T
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
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;
> +
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
opinions
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.
>
> http://archives.postgresql.org/
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
> >
> > Do
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 b
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 tha
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
Lamar Owen wrote:
[EMAIL PROTECTED]">
The low-latency and preemptible patches are not meant for performancegains, but for responsiveness, and are not designed to be used in servers,only in workstations/desktops.
ISTM that improving interactive performance would also improve mul
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
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 problem
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 wi
On Sun, Apr 14, 2002 at 02:35:13PM -0400, Lamar Owen wrote:
>
> Hmmm.
>
> 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).
The low-latency and preemptible patches are not meant fo
[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.
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
>> No, VACUUM has the same transactional constraints as everyone else
>> (unless you'd like a crash during VACUUM to trash your table...)
> Seriously, you can run VACUUM in a transaction and rollback the movement of
> a tuple on disk? What do
Gavin Sherry writes:
> The patch attached maintains backward compatibility. The syntax is as
> follows:
>
> COPY [BINARY] [WITH OIDS] FROM/TO
> [USING DELIMITERS ]
> [WITH [ DELIMITER | NULL AS | OIDS ]]
I think we should lose the WITH altogether. It's not any bet
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 modific
[EMAIL PROTECTED] writes:
> In 7.2.1, Both the WHEN and THEN clauses of a CASE statement are evaluated, even if
>the WHEN clause evaluates to FALSE.
Not in the normal case.
> SELECT
> CASE
> WHEN 1 = 2 THEN 1 / 0
> WHEN 1 = 1 THEN 1.0
> END;
> ERROR: floating point exce
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
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:
> > 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 tran
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 o
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 i
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
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
68 matches
Mail list logo
