Robert Haas writes:
> On Mon, May 5, 2014 at 1:53 PM, Tom Lane wrote:
>> A larger and more philosophical point is that such a direction of
>> development could hardly be called a "foreign" data wrapper. People
>> would expect Postgres to take full responsibility for such files,
>> including data
On Mon, May 5, 2014 at 1:53 PM, Tom Lane wrote:
> A larger and more philosophical point is that such a direction of
> development could hardly be called a "foreign" data wrapper. People
> would expect Postgres to take full responsibility for such files,
> including data integrity considerations s
On 05/05/2014 11:53 AM, Tom Lane wrote:
> Sure. They should all keep them outside $PGDATA, making it not-our-
> problem. When and if we're prepared to consider it our problem, we
> will be sure to advise people.
OK.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgs
Josh Berkus writes:
> On 05/05/2014 10:53 AM, Tom Lane wrote:
>> A larger and more philosophical point is that such a direction of
>> development could hardly be called a "foreign" data wrapper. People
>> would expect Postgres to take full responsibility for such files,
>> including data integrit
On 2014-05-05 11:17:18 -0700, Josh Berkus wrote:
> On 05/05/2014 10:53 AM, Tom Lane wrote:
> > Josh Berkus writes:
> >> I'm working with the cstore_fdw project, which has an interesting
> >> property for an FDW: the FDW itself creates the files which make up the
> >> database. This raises a coup
On Mon, May 5, 2014 at 8:17 PM, Josh Berkus wrote:
> On 05/05/2014 10:53 AM, Tom Lane wrote:
> > Josh Berkus writes:
> >> I'm working with the cstore_fdw project, which has an interesting
> >> property for an FDW: the FDW itself creates the files which make up the
> >> database. This raises a
On 05/05/2014 10:53 AM, Tom Lane wrote:
> Josh Berkus writes:
>> I'm working with the cstore_fdw project, which has an interesting
>> property for an FDW: the FDW itself creates the files which make up the
>> database. This raises a couple of questions:
>
>> 1) Do we want to establish a standar
Josh Berkus writes:
> I'm working with the cstore_fdw project, which has an interesting
> property for an FDW: the FDW itself creates the files which make up the
> database. This raises a couple of questions:
> 1) Do we want to establish a standard directory for FDWs which create
> files, such
On Mon, May 5, 2014 at 2:26 PM, Josh Berkus wrote:
>
> All,
>
> I'm working with the cstore_fdw project, which has an interesting
> property for an FDW: the FDW itself creates the files which make up the
> database. This raises a couple of questions:
>
> 1) Do we want to establish a standard dir
All,
I'm working with the cstore_fdw project, which has an interesting
property for an FDW: the FDW itself creates the files which make up the
database. This raises a couple of questions:
1) Do we want to establish a standard directory for FDWs which create
files, such as $PGDATA/base/{database
* Magnus Hagander (mag...@hagander.net) wrote:
> Currently, tablespace options (such as random_page_cost) aren't shown in
> \db or \db+ in psql - the only way to see them is to directly query
> pg_tablespaces. This seems like an oversight from back when the feature was
> added.
>
> I realize the C
Currently, tablespace options (such as random_page_cost) aren't shown in
\db or \db+ in psql - the only way to see them is to directly query
pg_tablespaces. This seems like an oversight from back when the feature was
added.
I realize the CF is closed, but would people be ok with me pushing this
tr
[EMAIL PROTECTED] schrieb:
I'd like to mimic MySQL's in-memory tables (engine=memory), which structure
survives a server restart (data lost of course).
I suspected that a server restart would be a problem in this case.
Thank you anyway.
you could use temp tables... but usually it isnt worth the
I'd like to mimic MySQL's in-memory tables (engine=memory), which structure
survives a server restart (data lost of course).
I suspected that a server restart would be a problem in this case.
Thank you anyway.
Paolo
Tino Wildenhain <[EMAIL PROTECTED]> ha scritto
> [EMAIL PROTECTED] schrieb:
> >
[EMAIL PROTECTED] schrieb:
Hi,
does anyone have experiences about putting a tablespace on ramdisk? Does it
work (and keep working after a restart of the server)?
Thanks in advance for any insight.
Yes it does work as long as you dont restart your server.
Postgres does not appreciate disappearin
Hi,
does anyone have experiences about putting a tablespace on ramdisk? Does it
work (and keep working after a restart of the server)?
Thanks in advance for any insight.
Paolo
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
On K, 2005-06-01 at 14:00 +0200, Dawid Kuroczko wrote:
> On 6/1/05, Zeugswetter Andreas DAZ SD <[EMAIL PROTECTED]> wrote:
> > You could create a separate bufferpool per page size. Of course that
> > has other disadvantages.
> >
> > Is it really so difficult to create and attach another shmem segme
On 6/1/05, Zeugswetter Andreas DAZ SD <[EMAIL PROTECTED]> wrote:
> You could create a separate bufferpool per page size. Of course that
> has other disadvantages.
>
> Is it really so difficult to create and attach another shmem segment ?
Well, I don't think it is much different from having two da
> The problem I see with this proposal is that the buffer manager knows
> how to handle only a equally-sized pages. And the shared memory stuff
> gets sized according to size * num_pages. So what happens if a certain
> tablespace A with pagesize=X gets to have a lot of its pages cached,
> evicti
On Tue, 2005-05-31 at 17:05 -0400, Tom Lane wrote:
> "Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> > I'm sure this has been thought of but was wondering whether anyone had
> > discussed the allowance of run-time block size specifications at the
> > tablespace level?
>
> Can you produce any evi
Tom,
You and I both know that depending on the application and data,
different block sizes are beneficial. As for actual statistics due to
overhead, I don't know what I can give you.
I can provide stats from an application which fits the case for multiple
block sizes on Oracle, but Oracle a
On Tue, May 31, 2005 at 02:55:29PM -0600, Jonah H. Harris wrote:
> Hey everyone,
>
> I'm sure this has been thought of but was wondering whether anyone had
> discussed the allowance of run-time block size specifications at the
> tablespace level? I know that a change such as this would substant
Yes,
That is what I/my clients have been discussing. It is a nifty
performance feature.
Bricklen Anderson wrote:
Jonah H. Harris wrote:
Hey everyone,
I'm sure this has been thought of but was wondering whether anyone
had discussed the allowance of run-time block size specifications at
Jonah H. Harris wrote:
Hey everyone,
I'm sure this has been thought of but was wondering whether anyone had
discussed the allowance of run-time block size specifications at the
tablespace level? I know that a change such as this would substantially
impact buffer operations, transactions, acc
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> I'm sure this has been thought of but was wondering whether anyone had
> discussed the allowance of run-time block size specifications at the
> tablespace level?
Can you produce any evidence whatsoever that this could be worth the cost?
Aside from
Hey everyone,
I'm sure this has been thought of but was wondering whether anyone had
discussed the allowance of run-time block size specifications at the
tablespace level? I know that a change such as this would substantially
impact buffer operations, transactions, access methods, the storage
Marc G. Fournier wrote:
>
> I have someone that is asking if you can recover some tablespaces in a
> database, but leave the others online ... apparently its a feature of
> tablespaces under Oracle ... I could see it for schemas, but sounds like
> it could cause problems depeending on how you a
I have someone that is asking if you can recover some tablespaces in a
database, but leave the others online ... apparently its a feature of
tablespaces under Oracle ... I could see it for schemas, but sounds like
it could cause problems depeending on how you are using tablespaces ...
Mar
At 03:14 PM 20/08/2004, Tom Lane wrote:
If we attempt
to reload this mess with a different default tablespace for the parent
object, what happens to the child in each case?
ISTM that for a table create with CREATE TABLE...TABLESPACE we should try
to preserve the tablespace when doing a dump/restor
Dear Philip,
> >I can give a hand about the implementation over the week-end, [...]
>
> I'm happy to do the pg_dump changes, assuming Tom gets the SET stuff sorted
> out. But would appreciate it if you could do some testing.
Ok. Just tell me.
As European/American/Asian timezones are involved, i
At 06:14 PM 20/08/2004, Fabien COELHO wrote:
This prior SET option looks much better and cleaner. Maybe the TOC entry
update is not really necessary if the SET is separate?
I'd prefer if it was separate since we want to minimize the number of
multi-statement TOC entries...I think. A new TOC entry
Dear Philip,
> Actually I was thinking of a little more than a setting to ignore errors;
> we would need to:
>
> - modify pg_dump to store the tablespace name as a separate
> part of the TOC entry, NOT as part of the CREATE TABLE.
> - modify pg_restore to issue 'set default tablespa
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Has anyone tested inheritance with tablespaces? ie. child in different
> tablespace to parent, select query that goes over both...?
They're at completely different levels of the system ... I'd be as
surprised to hear of a bug here as to hear
We already have some TODO items about sorting out exactly how the
defaulting behavior works here. In particular, what if anything is the
difference between a child object inheriting a default tablespace TS,
and explicitly saying "TABLESPACE TS" in its definition? If we attempt
to reload this mess
Actually I think we'd just revert the ruleutils.c change that showed
TABLESPACE in pg_get_indexdef. The real question is to be sure that
pg_dump could get along without it. If Philip wants to fix pg_dump,
I'm content to just stay out of his way ;-)
Well my original patch did without it, someone
Philip Warner <[EMAIL PROTECTED]> writes:
> Just to confirm; it's only tables and indexes that have tablespaces, and I
> can issue some kind of SET command. Any idea of the syntax?
> As an aside: should a database be allowed to have a default tablespace?
Well, tables and indexes definitely have
At 02:27 PM 20/08/2004, Tom Lane wrote:
Actually I think we'd just revert the ruleutils.c
Just to confirm; it's only tables and indexes that have tablespaces, and I
can issue some kind of SET command. Any idea of the syntax?
As an aside: should a database be allowed to have a default tablespace?
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> One point here is the handling of index tablespaces. I added TABLESPACE
>> as part of "pg_get_indexdef" output, but we'd need a different solution
>> if we want to go down this path.
> Another parameter to pg_get_indexdef() :(
Actually I thi
What have I missed? I can do the pg_dump stuff if noone else wants to.
I'm all of a sudden really busy :( Extra karate at nights + new
responsibilities at work, so my plan on doing the stuff listed for
pg_dump under TODO (specifically comments on index and composite type
columns) is rather lagg
One point here is the handling of index tablespaces. I added TABLESPACE
as part of "pg_get_indexdef" output, but we'd need a different solution
if we want to go down this path. Maybe it's not a problem given this
idea about where pg_dump is going to specify tablespace. But someone
needs to take
At 01:47 PM 20/08/2004, Tom Lane wrote:
But someone
needs to take a close look at pg_dump's logic to see if this can work.
Not sure where the issues lie, but anything that can reside in a tablespace
(table, index,...anything else?), needs to dump it's definition without
reference to a tablespace,
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> The problem with ALTER TABLE is that it can be hugely expensive, I think.
As long as you did it before loading any data, it wouldn't be too bad.
But certainly a preceding SET would be cheaper than pushing even
zero-size files around.
I don't have any p
Alvaro Herrera wrote:
> On Fri, Aug 20, 2004 at 01:26:39PM +1000, Philip Warner wrote:
> > At 01:09 PM 20/08/2004, Tom Lane wrote:
> > >It seemed like a reasonable idea to me...
> >
> > Do we have a "SET DEFAULT TABLESPACE"? Can we add one for this release? If
> > not, we probably need to go with
On Fri, Aug 20, 2004 at 01:26:39PM +1000, Philip Warner wrote:
> At 01:09 PM 20/08/2004, Tom Lane wrote:
> >It seemed like a reasonable idea to me...
>
> Do we have a "SET DEFAULT TABLESPACE"? Can we add one for this release? If
> not, we probably need to go with the ALTER TABLE. Although a SET D
At 01:09 PM 20/08/2004, Tom Lane wrote:
It seemed like a reasonable idea to me...
Do we have a "SET DEFAULT TABLESPACE"? Can we add one for this release? If
not, we probably need to go with the ALTER TABLE. Although a SET DEFAULT
TABLESPACE would be convenent in general.
Philip Warner <[EMAIL PROTECTED]> writes:
> At 12:37 PM 20/08/2004, Bruce Momjian wrote:
>> But that doesn't fix ascii dumps loaded via psql.
> It does; the ascii dump file is generated by exactly the same technique as
> pg_restore.
Right. Philip's suggestion would essentially use the same tech
At 12:37 PM 20/08/2004, Bruce Momjian wrote:
But that doesn't fix ascii dumps loaded via psql.
It does; the ascii dump file is generated by exactly the same technique as
pg_restore.
Internally, pg_dump builds a TOC, then calls RestoreArchive to dump the
text. It was designed this way for a bunch
Philip Warner wrote:
> At 02:33 AM 20/08/2004, Bruce Momjian wrote:
> > > Could we 'set default tablespace xxx', then have pg_dump/restore use a
> > > 'create table' that does not refer to the tablespace?
> >
> >That is what I was assuming. You can't retroactively change the dump
> >file during re
At 02:33 AM 20/08/2004, Bruce Momjian wrote:
> Could we 'set default tablespace xxx', then have pg_dump/restore use a
> 'create table' that does not refer to the tablespace?
That is what I was assuming. You can't retroactively change the dump
file during restore so we would have some SET varaiable
Dear Tom,
> > as many dummy and unknown ... tablespaces
>
> There are any number of ways to find it out --- read the output of
> "pg_restore -s", or just try the restore and observe the errors.
Ok, you're right on this point.
But I'm looking for something cleaner than grepping pg_restore output
Philip Warner wrote:
> At 12:21 AM 20/08/2004, Tom Lane wrote:
> >You can give it a new paint job in 8.1, if you like.
>
> To side-step the issue, is there a tablespace equivalent of a default schema?
>
> Could we 'set default tablespace xxx', then have pg_dump/restore use a
> 'create table' tha
Tom Lane wrote:
> Fabien COELHO <[EMAIL PROTECTED]> writes:
> > Just call that a kludge as it means that the admin is expected to create
> > as many dummy and unknown (if you have a custom dump file)
> > tablespaces
>
> There are any number of ways to find it out --- read the output of
> "pg_resto
At 12:21 AM 20/08/2004, Tom Lane wrote:
You can give it a new paint job in 8.1, if you like.
To side-step the issue, is there a tablespace equivalent of a default schema?
Could we 'set default tablespace xxx', then have pg_dump/restore use a
'create table' that does not refer to the tablespace?
-
Fabien COELHO <[EMAIL PROTECTED]> writes:
> Just call that a kludge as it means that the admin is expected to create
> as many dummy and unknown (if you have a custom dump file)
> tablespaces
There are any number of ways to find it out --- read the output of
"pg_restore -s", or just try the restor
Gavin Sherry wrote:
On Wed, 18 Aug 2004, Gaetano Mendola wrote:
Gavin Sherry wrote:
On Wed, 18 Aug 2004, Gaetano Mendola wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
now that we have the tablespace support don't you think that
each tablespace needs his own costs instead of a syste
> In point of fact I think this discussion is much ado about nothing, as
> there is already a workaround
Just call that a kludge as it means that the admin is expected to create
as many dummy and unknown (if you have a custom dump file) tablespaces as
necessary to please pg_restore.
These usele
Dear Bruce,
> > Bruce - pg_dump TODO for --no-tablespace or something?
>
> Uh, TODO already has:
>
> * Allow database recovery where tablespaces can't be created
>
> When a pg_dump is restored, all tablespaces will attempt to be created
> in their original locations. If this fails, the user m
hi all,
I am porting all my data from oracle to postgres :) . I want
to know where can I put the tables which existed in nulltablespace in
oracle. How is the nullTablespace different from default table space
and how is this done in postgres .
--
"Stand for something, or you will fall for
> > If the location doesn't exist will postgresql try to create it? istm
> > it could do this and if it fails then you are no worse off, but if it
> > were to succeed you're that much better off.
>
> Yea, I assume if you can't create the tablespace you put everything for
> that tablespace in the d
Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > If the location doesn't exist will postgresql try to create it? istm it could
> > do this and if it fails then you are no worse off, but if it were to succeed
> > you're that much better off.
>
> I think this would be fairly pointless
Robert Treat wrote:
> On Wednesday 18 August 2004 21:39, you wrote:
> > Christopher Kings-Lynne wrote:
> > > > It is a little bit different because a schema, a table or a function
> > > > are database application issues and are normally addressed by pg_dump
> > > > and pg_restore, although tablespa
Robert Treat <[EMAIL PROTECTED]> writes:
> If the location doesn't exist will postgresql try to create it? istm it could
> do this and if it fails then you are no worse off, but if it were to succeed
> you're that much better off.
I think this would be fairly pointless. In most of the practical
On Wednesday 18 August 2004 21:39, you wrote:
> Christopher Kings-Lynne wrote:
> > > It is a little bit different because a schema, a table or a function
> > > are database application issues and are normally addressed by pg_dump
> > > and pg_restore, although tablespaces are more an administration
Christopher Kings-Lynne wrote:
> > It is a little bit different because a schema, a table or a function are
> > database application issues and are normally addressed by pg_dump and
> > pg_restore, although tablespaces are more an administration issue wrt disk
> > layout and the like, which are lik
The first is to add a parameter to CREATE TABLESPACE and ALTER TABLESPACE
called RANDOMPAGECOST (or something like that) which allows users to set
the random page cost for a given tablespace. I'm undecided as to whether
they should be able to set the sequential scan cost. That seems
reasonable too
It is a little bit different because a schema, a table or a function are
database application issues and are normally addressed by pg_dump and
pg_restore, although tablespaces are more an administration issue wrt disk
layout and the like, which are likely to be different from one machine to
another
On Wed, 18 Aug 2004, Gaetano Mendola wrote:
> Gavin Sherry wrote:
>
> > On Wed, 18 Aug 2004, Gaetano Mendola wrote:
> >>-BEGIN PGP SIGNED MESSAGE-
> >>Hash: SHA1
> >>
> >>Hi all,
> >>now that we have the tablespace support don't you think that
> >>each tablespace needs his own costs instea
Gavin Sherry wrote:
On Wed, 18 Aug 2004, Gaetano Mendola wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
now that we have the tablespace support don't you think that
each tablespace needs his own costs instead of a system wide
one ?
I searched in the archives and on the TODO list witho
Dear Robert,
> Chris, help me understand this will you?
I'm not Chris, but it looks like Robert may eventually share my concerns,
so I'm happy not to be alone on this one ;-)
> On my production system I have a few very large tables I want to move
> into their own tablespace so I can but them a
On Wednesday 18 August 2004 04:39, Christopher Kings-Lynne wrote:
> > shell> pg_dump coelho | grep TABLESPACE
> > CREATE SCHEMA test AUTHORIZATION coelho TABLESPACE test;
> >
> > "TABLESPACE" appears in a basic pg_dump SQL output. If the test
> > tablespace does not exist, the command will fail, an
On Wed, 18 Aug 2004, Gaetano Mendola wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi all,
> now that we have the tablespace support don't you think that
> each tablespace needs his own costs instead of a system wide
> one ?
>
> I searched in the archives and on the TODO list withou
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
now that we have the tablespace support don't you think that
each tablespace needs his own costs instead of a system wide
one ?
I searched in the archives and on the TODO list without success.
Regards
Gaetano Mendola
-BEGIN PGP SIGNATURE
Dear Christopher,
> > "TABLESPACE" appears in a basic pg_dump SQL output. If the test tablespace
> > does not exist, the command will fail, and so my whole restoration.
> >
> > Thus I still stick to my opinion;-)
>
> Your complaint was that you need a way of continuing a restore if the
> _tablesp
shell> pg_dump coelho | grep TABLESPACE
CREATE SCHEMA test AUTHORIZATION coelho TABLESPACE test;
"TABLESPACE" appears in a basic pg_dump SQL output. If the test tablespace
does not exist, the command will fail, and so my whole restoration.
Thus I still stick to my opinion;-)
Your complaint was that
> > I'm not thinking about pg_dumpall but pg_dump/pg_restore.
>
> Tablespaces are dumped by pg_dumpall, not pg_dump.
If so, indeed it would be a non-issue. However,
shell> pg_dump coelho | grep TABLESPACE
CREATE SCHEMA test AUTHORIZATION coelho TABLESPACE test;
"TABLESPACE" appears in a basic p
At restore time it doesn't do anything since pg_dumpall is a text format
only.
I'm not thinking about pg_dumpall but pg_dump/pg_restore.
Tablespaces are dumped by pg_dumpall, not pg_dump.
Chris
---(end of broadcast)---
TIP 4: Don't 'kill -9' the post
Dear Christopher,
> > Allow database recovery where tablespaces can't be created
>
> How is that at all a problem?
It is enough a small problem to be put in the todo list.
> It's no different to the requirement to have installed all your contrib
> .so's before running your restore, what's s
IMVHO, I think the following todo item should make it for 8.0:
Allow database recovery where tablespaces can't be created
When a pg_dump is restored, all tablespaces will attempt to be
created in their original locations. If this fails, the user must
be able to adjus
We decided it didn't make much sense to allow the on-row sequences to be
anywhere but the default tablespace.
Hmmm...
I can understand the performance/utility rationale, but I don't like the
lack of orthogonality on principle. I like elegance;-) As a sequence looks
a lot like a table, I guess it s
> > (1) the "CREATE SEQUENCE foo TABLESPACE disk2" syntax does not seem
> > to be implemented.
>
> This is intentional. Sequences are not large enough to need to be
> pushed around among multiple tablespaces. Also, if we did allow
> sequences to be associated with tablespaces, we'd be preclu
Fabien COELHO <[EMAIL PROTECTED]> writes:
> (1) the "CREATE SEQUENCE foo TABLESPACE disk2" syntax does not seem
> to be implemented.
This is intentional. Sequences are not large enough to need to be
pushed around among multiple tablespaces. Also, if we did allow
sequences to be associated wi
> > > and afaik it is on Bruce's Beta-TODO list too.
> > Argh, I missed this one! Is it somewhere on line?
> Yep, URL at the top:
Quite an unexpected location! thanks for the pointer.
> Current version at ftp://momjian.postgresql.org/pub/postgresql/open_items.
IMVHO, I think the following todo
Fabien COELHO wrote:
>
> Dear Bruce,
>
> > > (1) the "CREATE SEQUENCE foo TABLESPACE disk2" syntax does not seem
> > > to be implemented.
> > >
> > > (2) when creating an implicit sequence with SERIAL, the sequence
> > > is created in the tablespace of the schema/database, not the one
> >
Dear Bruce,
> > (1) the "CREATE SEQUENCE foo TABLESPACE disk2" syntax does not seem
> > to be implemented.
> >
> > (2) when creating an implicit sequence with SERIAL, the sequence
> > is created in the tablespace of the schema/database, not the one
> > of the table, although indexes a
Fabien COELHO wrote:
>
> > > (3) psql auto completion does not have "CREATE/DROP TABLESPACE" in
> > > its list.
> >
> > I have already posted a patch for
> > this(http://candle.pha.pa.us/mhonarc/patches/msg0.html)
>
> Good. I should have checked the pending patch queue.
>
> > and afaik i
Fabien COELHO wrote:
>
> Dear hackers,
>
> Some minor comments about the new tablespace feature in 8.0beta1:
>
> It seems to me that tablespaces and sequences are not yet prefectly
> integrated.
>
> (1) the "CREATE SEQUENCE foo TABLESPACE disk2" syntax does not seem
> to be implemented.
>
> > (3) psql auto completion does not have "CREATE/DROP TABLESPACE" in
> > its list.
>
> I have already posted a patch for
> this(http://candle.pha.pa.us/mhonarc/patches/msg0.html)
Good. I should have checked the pending patch queue.
> and afaik it is on Bruce's Beta-TODO list too.
Argh
Fabien COELHO wrote:
(3) psql auto completion does not have "CREATE/DROP TABLESPACE" in
its list.
I have already posted a patch for
this(http://candle.pha.pa.us/mhonarc/patches/msg0.html) and afaik it
is on Bruce's Beta-TODO list too.
Stefan
---(end of broadcast)-
Dear hackers,
Some minor comments about the new tablespace feature in 8.0beta1:
It seems to me that tablespaces and sequences are not yet prefectly
integrated.
(1) the "CREATE SEQUENCE foo TABLESPACE disk2" syntax does not seem
to be implemented.
(2) when creating an implicit sequence with
I posted a patch for this last Friday 13th.
Gavin
On Mon, 16 Aug 2004, Bruce Momjian wrote:
>
> Added to TODO;
>
> o Add ALTER INDEX syntax to work like ALTER TABLE indexname
>
> ---
>
> Christopher Kings-Lynne wrote
Added to TODO;
o Add ALTER INDEX syntax to work like ALTER TABLE indexname
---
Christopher Kings-Lynne wrote:
> > What I mean here is that I think it would be in our best interests to
> > define the syntax for any n
Added to TODO:
o Add ALTER INDEX that works just like ALTER TABLE already does
on an index
---
Robert Treat wrote:
> On Tuesday 10 August 2004 22:13, Christopher Kings-Lynne wrote:
> > > What I mean here
On Tuesday 10 August 2004 22:13, Christopher Kings-Lynne wrote:
> > What I mean here is that I think it would be in our best interests to
> > define the syntax for any new operation to be as easily guessed as
> > possible. I believe that ALTER INDEX would be more easily guessed by
> > more people
What I mean here is that I think it would be in our best interests to
define the syntax for any new operation to be as easily guessed as
possible. I believe that ALTER INDEX would be more easily guessed by
more people as the means by which one would alter an index's tablespace
than ALTER TABLE, ev
I wrote:
> I'm certainly not arguing for a wholesale rework of the syntax in order
> to achieve maximum consistency (nice as that might be), but it seems to
> me that it would be a mistake to introduce more inconsistency than is
> already there when it's not necessary to do so.
What I mean here is
Tom Lane wrote:
> Kevin Brown <[EMAIL PROTECTED]> writes:
> > ... But what we're talking about
> > here is brand new functionality for which the language hasn't been
> > defined yet.
>
> You're missing the point, which is that there *is* a precedent of long
> standing. ALTER TABLE has worked on
Kevin Brown <[EMAIL PROTECTED]> writes:
> ... But what we're talking about
> here is brand new functionality for which the language hasn't been
> defined yet.
You're missing the point, which is that there *is* a precedent of long
standing. ALTER TABLE has worked on indexes (and sequences, and vi
Christopher Kings-Lynne wrote:
> >>Errr, unlike all the other uses for alter table and friends? ie:
> >>
> >>OWNER TO
> >
> >Which changes the attributes of the table...
>
> And indexes.
Sure. But not *just* indexes.
> >>RENAME TO
> >
> >Same.
>
> And indexes.
It does? I thought the indexes
Errr, unlike all the other uses for alter table and friends? ie:
OWNER TO
Which changes the attributes of the table...
And indexes.
RENAME TO
Same.
And indexes.
SET TABLESPACE
Which again changes the attributes of the table..
And indexes.
Chris
---(end of broadcast)--
Christopher Kings-Lynne wrote:
> >Hmm...not ALTER INDEX? Now that there's an operation that actually
> >modifies an index instead of the table itself, should there be an ALTER
> >INDEX? It would be cleaner and more consistent, IMO...
>
> Errr, unlike all the other uses for alter table and friend
1 - 100 of 123 matches
Mail list logo
