> Actually, what we need to do to reclaim space is to enable table
> recreation without the column, now that we have relfilenode for file
> renaming. It isn't hard to do, but no one has focused on it. I want to
> focus on it, but have not had the time, obviously, and would be very
> excited to a
Hi,
I'm working on making the SHOW command dump its output as if it were a
select result.
Tom's declared the following as static ("private") methods?
static TextOutputState *begin_text_output(CommandDest dest, char *title);
static void do_text_output(TextOutputState *tstate, char *aline);
stati
> > I should really move these off somewhere else and make them a bit more
> > global and generic.
>
> What's insufficiently generic about them for you?
Well, at a _quick_ glance they're designed only for one column output...
Chris
---(end of broadcast)
> Fine. I'll work on that basis. I'll prepare a full-blown patch which can
> be applied Monday -unless anyone else is sitting on uncommitted changes
> to the directory that they want me to wait for?
Nothing important. Shall I suggest that you do the rearrangement first, and
then once everything'
> To my humble opinion, KDE needs a real database abstraction layer (like
> pgSchema) with a multi-vendor interface. The only solution today is Gnome
> libgda. Unfortunately, libgda is not well-written. A good
> abstraction layer
> needs inheritence (C++, not C) and XML to handle specfic features
> Updating pg_attribute per se is not so hard --- just store new copies of
> all the rows for the table. However, propagating the changes into other
> places could be quite painful (I'm thinking of column numbers in stored
> constraints, rules, etc).
>
> It seems to me that reducing the column to
> > thought out way of predicting/limiting their size. (2) How the heck do
> > you get rid of obsoleted cached plans, if the things stick around in
> > shared memory even after you start a new backend? (3) A shared cache
> > requires locking; contention among multiple backends to access that
> >
> Jan, regression is not a test of the level a developer would use to make
> sure his code works. It is merely to make sure the install works on a
> limited number of cases.
News to me! If anything, I don't think a lot of the current regression
tests are comprehensive enough! For the SET/DROP
Does it cache all queries or just explicitly prepared ones?
Does is check for cached queries all the time or just explicitly EXECUTED
ones?
Chris
- Original Message -
From: "Neil Conway" <[EMAIL PROTECTED]>
To: "PostgreSQL Hackers" <[EMAIL PROTECTED]>
Sent: Sunday, April 14, 2002 6:47 A
Does it cache all queries or just explicitly prepared ones?
Does is check for cached queries all the time or just explicitly EXECUTED
ones?
Chris
- Original Message -
From: "Neil Conway" <[EMAIL PROTECTED]>
To: "PostgreSQL Hackers" <[EMAIL PROTECTED]>
Sent: Sunday, April 14, 2002 6:47 A
> 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 you mean by same transactional constraints?
Chris
--
> Just explicitly prepared ones. Caching all queries opens a can of
> worms that I'd rather not deal with at the moment (volunteers to
> tackle this problem are welcome).
I definitely agree. I think that the optimisation possiblities offered to
the DBA for shared prepared statements are quite la
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
> 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
> As you can see from the schema I gave later in my message, that's
> exactly what I did. But does this actually avoid allocating the
> space in the on-disk tuples? What part of the code deals with this?
> It looks to me like the four bytes for the OID are still allocated
> in the tuple, but not u
>b) In fact, at times I don't need that data integrity. I'm
> prefectly
>happy to risk the loss of a table during import, if it
> lets me do the
>import more quickly, especially if I'm taking the database off line
>to do the import anyway. MS SQL server in fact allo
> On Monday 15 April 2002 03:53, Christopher Kings-Lynne wrote:
> > BTW, instead of:
> >
> > CREATE UNIQUE INDEX bigone_pkey ON bigone (rec_no);
> >
> > do:
> >
> > ALTER TABLE bigone ADD PRIMARY KEY(rec_no);
>
> I am sorry, could you please el
> Yes, I know. I mean how does this affect performance? How this can change
> planner decision? Does it have any effect except cosmetical one?
Only cosmetic. In the example he gave, he wanted a primary key, so I showed
him how to make one properly.
Chris
---(end of bro
Hi,
I'm thinking of doing a patch to generate foo_fkey and foo_chk names for
fk's and checks. I know that this will make using DROP CONSTRAINT a whole
heck of a lot easier. There have also been a few people who've complained
on the list about all the foreign keys, etc.
I know Tom had some fea
> Actually I'm in favor of it. I have a proposal outstanding to require
> constraints to have names that are unique per-table, for consistency
> with triggers (already are that way) and rules (will become that way,
> rather than having globally unique names as now). AFAIR the only
> significant
> > Anyway, how does one measure the perfomance impact of such a change?
> > By merely changing the constant definition, or also by actually using
> > long identifiers? I can do that if it's of any help, for various values
> > perhaps.
>
> I think I would measure disk size change in a newly create
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
1 - 100 of 2140 matches
Mail list logo
