The Firebird guys have gotten around to releasing 1.0. If you read this
front page spiel, you'll notice that they use MVCC, but with an overwriting
storage manager.
http://www.ibphoenix.com/ibp_act_db.html
The relevant extract:
"Multi-version concurrency control uses back versions of modified
I remember someone mentioning on the list that we should collect a list of
places that refer to postgres so that we can update them for a new release.
I just submitted an update on Linux.com:
http://software.linux.com/projects/postgresql/?topic=323,324,325
That location should be added to the l
l 2002 3:23 PM
> To: Christopher Kings-Lynne
> Cc: Hackers
> Subject: Re: [HACKERS] Places to update when a new version is out
>
>
> Hi Chris,
>
> I don't have time at the moment to start making the needed document. :(
>
> Does anyone want to throw t
> I have bitched about the index stuff for a while, and always have
> bumped up
> against this problem. If I can sway anyone's opinion, I would say, unless
> (using Tom's words) a "factor of 2" planner difference against, I
> would use an
> index. Rather than needing clear evidence to use an index
> If the DBA notices that there is a problem with a query, he adds
> an index, he
> notices that there is no difference, then he notices that
> PostgreSQL is not
> using his index. First and foremost he gets mad at PostgreSQL for
> not using his
> index. If PostgreSQL decided to use an index which
> TODO updated:
>
> > * Add BETWEEN ASYMMETRIC/SYMMETRIC (Christopher)
> > * Christopher is Christopher Kings-Lynne <[EMAIL PROTECTED]>
So should I go ahead and submit a patch for BETWEEN that adds SYMMETRY
support in the old-style code, and then at a later stage s
> > So should I go ahead and submit a patch for BETWEEN that adds SYMMETRY
> > support in the old-style code, and then at a later stage submit
> a patch that
> > makes BETWEEN a proper node?
>
> Sure, I think that makes sense. The larger BETWEEN node code will be
> tricky.
Question: Why have you
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> > So should I go ahead and submit a patch for BETWEEN that adds SYMMETRY
> > support in the old-style code, and then at a later stage submit
> a patch that
> > makes BETWEEN a proper node?
>
>
> Neil Conway <[EMAIL PROTECTED]> writes:
> > I'm planning to re-implement PREPARE/EXECUTE with support only
> > for locally-prepared plans, using the existing patch as a
> > guide. The result should be a simpler patch -- once it's
> > in CVS we can worry about more advanced plan caching
> > techi
> Neil Conway <[EMAIL PROTECTED]> writes:
> > I'm planning to re-implement PREPARE/EXECUTE with support only
> > for locally-prepared plans, using the existing patch as a
> > guide. The result should be a simpler patch -- once it's
> > in CVS we can worry about more advanced plan caching
> > techi
Is this a bug?
usa=# SELECT * FROM palm_buyers WHERE buyer_id=in('150',210) ;
ERROR: Function 'in(unknown, int4)' does not exist
Unable to identify a function that satisfies the given argument
types
You may need to add explicit typecasts
Chris
---(end o
Ignore my previous post - for obvious reasons!!!
Chris
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
> Will we be able to accomplish the equivelent of the below?
>
>
> knight# ls -la
> total 3
> drwxr-xr-x 2 rbt rbt 512 Apr 18 21:53 .
> drwxr-xr-x 43 rbt rbt2048 Apr 18 21:36 ..
> -rwx-- 1 root wheel 0 Apr 18 21:53 file
>
> knight# head /etc/group
> # $FreeBSD: src/etc/gr
> But note that this is on TODO:
>
> * Allow user to control trigger firing order
>
> That probably means that the user should have some reasonable way to
> change the name, besides fiddling with system catalogs.
An ALTER TRIGGER command? Of course, it should not allow modification of
constraint
> and two macros:
>
> RECURSE_OVER_CHILDREN(relid);
> AlterTableDoSomething(childrel,...);
> RECURSE_OVER_CHILDREN_END;
>
> (this seems more straightforward than passing the text of the function
> call as a macro parameter).
The above all looks fine. The other stuff I wouldn't really know a
On FreeBSD/Alpha, current CVS:
gmake -C common SUBSYS.o
gmake[4]: Entering directory `/home/chriskl/pgsql/src/backend/access/common'
gcc -pipe -O -g -Wall -Wmissing-prototypes -Wmissing-declarations -I../../..
/../src/include -c -o heaptuple.o heaptuple.c -MMD
In file included from ../../../../
> For tracking of Foreign Keys, Check constraints, and maybe NULL / NOT
> NULL (specific type of check constraint) I intend to create (as per
> suggestion) pg_constraint.
Hmmm...I don't see the need at all for NOT NULL constraint tracking. The
spec doesn't seem to require it and we do not have n
> We have been very fortunate to have avoided such problems since we
> started six years ago, and I hope it never happens.
There sure are a lot of arguments in the hackers list tho :) I do wish
people would be a little less 'ad hominem' in their argument styles,
however.
It would be an interest
I showed this to my friend who's a FreeBSD committer (Adrian Chadd) and he's
actually setting up a MacOS/X box at the moment and will look into it -
assuming you don't discover the problem first...
Chris
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf
> Do we want this feature?
> -
> Based on the many posts on this topic, I think the answer to this is a
> resounding yes.
Definitely!
> How do we want the feature to behave?
> -
> A SRF should
> > JDBC and ODBC metadata code is certainly broken; so are the
> > catalog lookups in pgaccess, pgadmin, and so on. psql and
> > pg_dump are broken as well (though I will take responsibility
> > for fixing pg_dump, and will then look at psql if no one else
> > has done it by then). I'm not even
Hi,
PureFTPd has got really good Postgres support:
Authenticates off postgres, with definable queries to return stuff like
homedirs, quotas, password hashes, etc.
Cool.
Chris
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go
> test=# CREATE USER tgl;
> CREATE USER
> test=# CREATE SCHEMA tgl AUTHORIZATION tgl;
> CREATE
What about "CREATE USER tgl WITH SCHEMA;" ?
Which will implicitly do a "CREATE SCHEMA tgl AUTHORIZATION tgl;"
Chris
---(end of broadcast)---
TIP 1: s
> produces a result like this:
>
> schema | object
> +
> public | abc
> foo| abc
> foo| xyz
> bar| xyz
> (4 rows)
>
> How can I restrict the query to the schemas in the
> current search path, i.e. the schema names returned
> by SELECT current_schemas() ?
Now, if w
Hi all,
I'm having problems restoring a dump. I get this:
You are now connected as new user chriskl.
ERROR: Unrecognized language specified in a CREATE FUNCTION: 'plpgsql'.
Pre-installed languages are SQL, C, and internal.
Additional languages may be installed using 'createlang
Hi,
Is there any rhyme or reason to these ISO format date parsing rules?
test=# select '1-1-1'::date;
ERROR: Bad date external representation '1-1-1'
test=# select '69-1-1'::date;
date
2069-01-01
(1 row)
test=# select '50-1-1'::date;
date
2050-01-01
(1 row)
> > Rather than propagating the SysV semaphore API still further, why don't
> > we kill it now? (I'm willing to keep the shmem API, however.)
>
> Would this have the benefit of allow PostgreSQL to work properly in BSD
> jails, since lack of really working SysV IPC was the problem there?
I have p
> (For others: apparently PG will work under BSD jails if you recompile the
> BSD kernel w/some new settings, but my ISP for this project was
> unwilling to
> do that. Search the mailing list for messages on how to do this.)
Works fine. You don't need to recompile - just use the sysctl.
Chris
> IMHO, the current ADD COLUMN mechanism is a hack. Besides requiring
> redundant on-disk data (t_natts), it isn't SQL compliant (because
> default values or NOT NULL can't be specified), and depends on
> a low-level kludge (that the storage system will return NULL for
> any attnums > the # of the
> I forwarded the suggestion to my ISP (imeme, a Zope provider), who said
> that:
>
> "This will allow you to run a single postgres in a single jail only one
> user would have access to it. If you try to run more then one it will
> try to use the same shared memory and crash."
Not true. But I'
Feedback: you're a legend!
I'll try to patch my CVS and test it at some point...
Chris
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Joe Conway
> Sent: Tuesday, 7 May 2002 12:51 AM
> To: pgsql-hackers
> Subject: [HACKERS] Set Returning Functions
> It is my experience that most other free software projects take
> standards compliance more seriously than PostgreSQL, and my strong
> opinion that both the project and its users (not to mention the
> whole SQL database industry, eventually) would benefit from better
> support for the SQL standa
> I'm happy w/o the FORCE option (just let TRUNCATE do it), but if enough
> people think that the FORCE keyword should be added to allow overriding of
> triggers, that could be a good compromise.
>
> But, please, don't take away the ability to TRUNCATE. Doing it when there
> are triggers is one th
> > It seems to me that there's more and more need for an 'SET CONSTRAINTS
> > DISABLED' and 'SET CONSTRAINTS ENABLED' command that affects
> only foreign
> > keys.
>
> I really dislike the idea of referring to "constraints" but only affecting
> foreign key constraints.
All the other SET CONSTRAI
> Actually, even for those that wuldn't need the patch ... as long as the
> "default behaviour" doesn't change, and unless there are no valid
> technical arguments around it, there is no reason why a patch shouldn't be
> included ...
Unless it's going to interfere with implementing the general ca
Hi All,
I can't see that there's any way to reset the stats collector without HUPing
the postmaster? Is there? Should there be?
Chris
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail
Maybe Vince could set up a Win32 porting project page, and since we now seem
to have a few interested parties willing to code on a native Win32 version,
they should have their own project page. This could make communication
easier for them and make sure the project doesn't die...
Chris
> -O
Hi guys,
Just in case anyone is around, I've recently
arrived in Costa Mesa, California from Australia for a couple of weeks on
business. So, if anyone's in the area - it might be cool to catch
up...
Chris
Well, given that vacuum does its work in the background now - I think you'll
be hard pressed to find a sys admin who'll vote for leaving it as is, no
matter how small the chance of corruption.
However - this isn't my area of expertise...
Chris
- Original Message -
From: "Tom Lane" <[EMA
It's more likely that your changes will go through if you just submit a
patch!
cvs diff -c
Chris
- Original Message -
From: "Katherine Ward" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, May 30, 2002 2:33 PM
Subject: [HACKERS] Small changes to facilitate Win32 port
> Hi
> Christopher Kings-Lynne wrote:
> > It's more likely that your changes will go through if you just submit a
> > patch!
>
> I suggested to discuss it first, since it's IMHO more likely
> that the changes go through if they are commonly accepted in
&
> (OTOH one could make a good argument that now is the time to do it
> if we're ever gonna do it --- clients that are not schema-aware will
> be badly in need of work anyway for 7.3...)
Maybe the attisdropped column should be created and added to the
pg_attribute catalog now as well. It would al
FreeBSD man page for ctags:
-d Create tags for #defines that do not take arguments; #defines
that take arguments are tagged automatically.
-t Create tags for typedefs, structs, unions, and enums.
Chris
- Original Message -
From: "Mattew T. O'Connor" <[
> Tom Lane wrote:
> > Well, we're not doing that; and I see no good reason to make the thing
> > be a builtin function at all. Since it's just an example, it can very
> > well be a contrib item with a creation script. Probably *should* be,
> > in fact, because dynamically created functions are w
> Given the plethora of mutually incompatible interpretations that MSSQL
> evidently supports, though, I fear we can't use it as precedent for
> making any choices :-(.
>
> Can anyone check out other systems?
MySQL:
6.4.6 DELETE Syntax
DELETE [LOW_PRIORITY | QUICK] FROM table_name
[WHERE
We've got an OSX machine set up now, however we haven't had time to look
into the problem yet.
Chris
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of David Santinoli
> Sent: Tuesday, 11 June 2002 12:48 AM
> To: [EMAIL PROTECTED]
> Subject: [HACKERS]
> > What is a TRUNCATE TABLE but a drop create anyway? Is there some
> > technical difference?
> >
> It doesn't kill indexes/triggers/constraints/Foreign Key Stuff, etc.
Hrm - last time I checked it did...
Chris
---(end of broadcast)---
TIP 1:
Just so you know, current CVS HEAD passes all tests on FreeBSD/Alpha (a
64bit machine) with this configure:
./configure --prefix=/home/chriskl/local --enable-integer-datetimes --enable
-debug --enable-depend --enable-cassert --with-pam --with-openssl --with-CXX
Chris
--
> > Hrm - last time I checked it did...
>
> Two questions :
>
> When was the last time ?
7.1
> It did what ?
Drops triggers and stuff.
OK, I did a check and it looks like it's fixed in 7.2 at least. Sorry for
the false alarm...
Chris
---(end of broadcast)---
> Currently serial is dumped as a sequence and appropriate default
> statement.
>
> With my upcoming dependency patch serials depend on the appropriate
> column. Drop the column (or table) and the sequence goes with it.
> The depencency information does not survive the pg_dump / restore
> process
> I think that when SERIAL is used, the sequence should be tied
> inextricably to the table which created it, and it should be hidden from
> use for other purposes (perhaps similar to the way a toast table is). If
> you *want* to use a sequence across several tables, then you don't use
> SERIA
You wrote "was either to voluminous" instead of "was either too voluminous"
in the first paragraph of the appendix...
Chris
- Original Message -
From: "Thomas Lockhart" <[EMAIL PROTECTED]>
To: "PostgreSQL Hackers List" <[EMAIL PROTECTED]>
Sent: Saturday, June 15, 2002 1:16 PM
Subject: [H
: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Christopher
> Kings-Lynne
> Sent: Wednesday, 19 June 2002 2:30 PM
> To: Bruce Momjian
> Cc: Thomas Lockhart; Bruce Momjian - CVS;
> [EMAIL PROTECTED]
> Subject: Re: [COMMITTERS] pgsql/src/backend/parser gram.y
>
&
Althought that is in the contrib/bind directory. Searching again...
Chris
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Christopher
> Kings-Lynne
> Sent: Wednesday, 19 June 2002 2:41 PM
> To: Bruce Momjian; Hackers
>
This is the problem:
***
./expected/rules.out Fri May 3
08:32:19 2002--- ./results/rules.out Sun Jun 23 14:08:37
2002** 1005,1012 SELECT * FROM shoe_ready
WHERE total_avail >= 2; shoename | sh_avail
| sl_name | sl_avail | total_avail
+---
Hi All,
Whereabouts in the code is the '*' expanded into
the list of valid columns and also where are the columns specified in the select
arguments (or whereever) checked for validity?
Chris
> Some have expressed that this could be quite slow for large databases,
> and want a type of:
>
> SET CONSTRAINTS UNCHECKED;
>
> However, others don't believe constraints other than foreign keys
> should go unchecked.
Well, at the moment remember taht all that other SET CONSTRAINTS commands
only
I was thinking of writing a command line tool like 'pgtune' that looks at
the stats views and will generate SQL code for, or do automatically the
following:
* Dropping indices that are never used
* Creating appropriate indices to avoid large, expensive sequential scans.
This would put us in the
> Please, please, do not do that. Make a new expression node tree type,
> instead. We've made this mistake before (eg for BETWEEN) and I don't
> want to do it again.
I've actually already done almost all the work for converting BETWEEN to a
node but I have a couple of questions:
Should I use a
> The second seems more user-friendly but also seems to violate the
> principle of least surprise. Anyone have an opinion about what to do?
Sounds like a logical argument, given normal OO behaviour.
Hope it inspires someone to implement DROP COLUMN :)
Chris
---(end
> OK, I want to know, does anyone see MySQL gaining in market share in
> comparison to PostgreSQL, or is MySQL gaining against other databases?
> Is MySQL gaining sites faster than we are gaining sites?
>
> Every indication I can see is that PostgreSQL is gaining on MySQL.
>
> The Linux/FreeBSD co
> What other development options do we have for soemthing that is GUI and
> portable to all platforms that postgresql runs on? Java? wxWindows? Qt?
> Gtk? I would think that Gtk is probably the most portable, and it has
> bindings to many languages, but we would probalby want to use C.
TOra u
> > I wasn't really comparing to MySQL here. I meant, in relationship
> > to MS Access. Start it up and it just works.
>
> Yeah, a point-and-drool installation wizard for postgres under windows
> would be great. I think, from looking at PGAdminII, that we've already
> got great admin tools; it see
> > Yeah, a point-and-drool installation wizard for postgres under windows
> > would be great. I think, from looking at PGAdminII, that we've already
> > got great admin tools; it seems just as good as SQL Server Enterprise
> > Manager to me.
>
> Once we have a proper Win32 native version, the guy
> DROP TYPE widget RESTRICT; -- fail
> NOTICE: operator <% depends on type widget
> NOTICE: operator >% depends on type widget
> NOTICE: operator >=% depends on type widget
> ERROR: Cannot drop type widget because other objects depend on it
> Use DROP ... CASCADE to drop the dependent objects
Hmmm...
I think this is a common fallacy. It's like arguing that if windoze crashes
and you lose important data then you have some sort of legal recourse
against Microsoft. Ever read one of their EULAs? $10 says that Oracle's
license grants them absolute immunity to any kind of damages claim.
The cvs docs say that we support the 'WITH CHECK OPTION' on views, but the
TODO says we don't...
Chris
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Hi,
Based on recent discussion, I went thru and got together the work I'd done
on the BETWEEN node. It's not as far along as I thought. I ran into a few
hurdles:
* ExecEvalBetweenExpr is probably beyond my powers - I've done my best and
marked my hopelessness with '@@' symbols. I don't know h
> > Anyone else keen for this feature?
>
> Attached is a patch implementing this. The patch is against 7.2.1
> source. The grammar introduced is of the form:
>
> CREATE TEMP TABLE ... ON COMMIT DROP;
>
> Is this a desirable feature? Seems pretty useful to me.
It's useful, there's a patch - wh
> As for project coordination, I am willing to setup and maintain a page
> similar to the (horribly outdated) ones that I did for Toast and RI.
> Summarizing project status, pointing to resources, instructions, maybe a
> roadmap, TODO, you name it.
I am willing to supply a complete, friendly, pow
Hi All,
I've been thinking about this DROP COLUMN business (sorry to start another
spammy, flamey thread!). I'm taking ideas from lots of sources here.
How does this sound for a process?
1.
A new column is added to pg_attribute called 'attisdropped'. It, of course,
defaults to false.
2.
The
Hi Florian,
> > The most recent patches were submitted by me, so I guess you
> could call me
> > the defacto "maintainer".
>
> Okay - glad someone answered me :)
Actually, I replied to you 5 minutes after you posted, but I think my emails
were being stalled somewhere...
> I will - please give m
> 2.
> The column expansion (*) code and the code that checks for valid column
> references everywhere in the codebase is changed to also check the
> attisdropped field. Does someone have a comprehensive list of
> places to be
> changed?
Actually - did Hiroshi(?)'s original HACK have this code -
> > I am not at all sure that this aspect of Florian's change is a good
> > idea, as it appears to eliminate locale-awareness in favor of a hard
> > coded delimiter list.
>
> Just tried your example - you're right of course! I will remove the hard
> coded delimited list and replace it with the pro
> This part should fall out of Rod Taylor's pg_depend stuff pretty easily.
> We still need to debate about the behavior, though. If for example there
> is a unique index on column B, do you need "DROP B CASCADE" to get rid
> of it, or is "DROP B RESTRICT" good enough? Does your answer change if
> > It would all work out of the box and would do wonderful things for the
> > Postgres community.
>
> I like this idea, but let me just bring one little issue to note: are you
> going to handle upgrades, and if so, how? How are you going to
> do a major
> version upgrade?
Well, the easiest way
OK,
On HEAD, I am still seeing the attached failures. They didn't happen
before, but appeared in the last couple of months. All other tests pass.
It seems to just be a tuple ordering issue - I really don't know what caused
it? If necessary, I can just modify the expected result, but I haven't
> The nice thing about this implementation approach is that most of the
> backend need not be aware of deleted columns. There are a few places in
> the parser (probably few enough to count on one hand) that will have to
> explicitly check for and reject references to dropped columns, and
> you're
> Of course, a shared memory system probably is going to either do it
> sequentailly or have its own index issues, so I don't see a huge
> advantage to going to shared memory, and I do see extra code and a queue
> limit.
Is a shared memory implementation going to play silly buggers with the Win32
Is it included now in the main build process? If so, I'll test it on
FreeBSD/Alpha.
> Libpqxx still needs to be integrated:
>
> The 'configure' tests need to be merged into our main configure
> The documentation needs to be merged into our SGML docs.
> The makefile structure ne
OK, this is what I'm seeing on FreeBSD/Alpha for libpq++. I haven't figured
out how to build libpqxx yet.:
gmake[3]: Entering directory
`/home/chriskl/pgsql-head/src/interfaces/libpq++'
g++ -O2 -g -Wall -fpic -DPIC -I../../../src/interfaces/libpq -I../../../src/
include -c -o pgconnection.o pg
> One problem I see is that pg_constraint entries can *only* be associated
> with relations; so the table has no way to represent constraints
> associated with domains --- not to mention assertions, which aren't
> associated with any table at all. I'm in no hurry to try to implement
> assertions,
Hi All,
I have given up working on the BETWEEN node. It got to the stage where I
realised I was really out of my depth! Rod Taylor has indicated an interest
in the problem and I have sent him my latest patch, so hopefully he'll be
able to crack it.
So instead, I've taken up with the DROP COLUM
> I've not looked in a while, but the column rename code did not account
> for issues in foreign keys, etc. Those should be easier to ferret out
> soon, but may not be so nice to change yet.
Which is probably a good reason for us to offer it as an all-in-one command,
rather than expecting them t
> > > > Yes, please remind me. Was your solution renumbering the
> attno values?
> > >
> > > Yes though I don't intend to object to Christopher's proposal.
Hiroshi,
I am thinking of rolling back my CVS to see if there's code from your
previous test implementation that we can use. Apart from the
Hi,
I've attached the changes I've made to pg_attribute.h - I can't see what's
wrong but whenever I do an initdb it fails:
initdb -D /home/chriskl/local/data
The files belonging to this database system will be owned by user "chriskl".
This user must also own the server process.
The database clu
> > I am thinking of rolling back my CVS to see if there's code from your
> > previous test implementation that we can use. Apart from the DropColumn
> > function itself, what other changes did you make? Did you have
> > modifications for '*' expansion in the parser, etc.?
>
> Yes, please review
> > Well, obviously I prefer the attisdropped approach. I think
> it's clearer
> > and there's less confusion. As a head developer for phpPgAdmin
> that's what
> > I'd prefer... Hiroshi obviously prefers his solution, but
> doesn't object to
>
> OK, can you explain the issues from a server and
> Unfortunately many apps rely on the fact that the attnos are
> consecutive starting from 1. It was the main reason why Tom
> rejected my trial. Nothing has changed about it.
OK, I've been looking at Hiroshi's implementation. It's basically
semantically equivalent to mine from what I can see so
> > What's your point? No client that examines pg_attribute can be trusted
> > until it's been examined pretty closely (as in, more closely than
> > Christopher looked at pg_dump). I'd prefer to see us keep the backend
> > simple and trustworthy, rather than pursue a largely-illusory idea that
>
By the way,
What happens if someone drops ALL the columns in a table? Do you just leave
it there as-is without any columns or should it be forbidden or should it be
interpreted as a drop table?
Chris
---(end of broadcast)---
TIP 1: subscribe a
> True enough, but that's not a trivial difference. The problem with
> Hiroshi's implementation is that there's no longer a close tie between
> pg_attribute.attnum and physical positions of datums in tuples. I think
> that that's going to affect a lot of low-level code, and that he hasn't
> foun
> > No, he only breaks even for client cleanliness --- either approach
> > *will* require changes in clients that look at pg_attribute.
>
> Uh, Christopher already indicated three clients, psql, pg_dump, and
> another that will not require changes for Hiroshi's approach, but will
> require change
> My problem is that you are pushing the DROP COLUMN check out into almost
> every client that uses pg_attribute. And we are doing this to keep our
> backend cleaner. Seems we should do the work once, in the backend, and
> not burden clients will all of this.
As a user of Postgres, I found the
> BTW there seems a misunderstanding about my posting.
> I'm not objecting to add attisdropped pg_attribute column.
> They are essentially the same and so I used macros
> like COLUMN_IS_DROPPED in my implementation so that
> I can easily change the implementation to use isdropped
> pg_attribute col
> > Well, what happens if you rename a column in a child table?
> Same problem?
>
> It merrily renames the column in the child table (I tried it). When
> SELECTing the parent, bogus data appears. Looks like a bug to me.
> Maybe the ALTER TABLE ... RENAME COLUMN code should check for inherite
> OK, my guess is that it is checks in parser/. I would issue each of
> these queries with a non-existant column name, find the error message in
> the code, and add an isdropped check in those places.
OK, I think I've narrowed it down to this block of code in scanRTEForColumn
in parse_relation.c
> > I'm thinking that I should put a 'SearchSysCacheCopy' where my
> @@ comment is
> > to retrieve the attribute by name, and then do a check to see if it's
> > dropped. Is that the best/fastest way of doing things? Seems
> unfortunate
> > to add a another cache lookup in every parsed query...
>
> > I am still looking but perhaps you could supress dropped columns from
> > getting into eref in the first place.
>
> OK, that's done. I'm working on not allowing dropped columns in UPDATE
> targets now.
OK, I've fixed it so that dropped columns cannot be targetted in an update
statement, howe
> > test=# create table test (a int4, b int4, c int4, d int4);
> > CREATE TABLE
> > test=# insert into test values (1,2,3,4);
> > INSERT 16588 1
> > test=# alter table test drop b;
> > ALTER TABLE
> > test=# select * from test;
> > a | d | d
> > ---+---+---
> > 1 | 3 | 4
> > (1 row)
>
> What of
201 - 300 of 1502 matches
Mail list logo
