Bruce Momjian <[EMAIL PROTECTED]> writes:
> I have a few other questions:
> What is the procedure for moving tablespace directories?
There is none.
> However, pg_tablespace still has the old location.
Yup. The *only* thing that pg_tablespace.spclocation is used for is
for pg_dumpall to dump ap
On Fri, 18 Jun 2004, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > OK, I have reviewed the patch. I think Tom is doing the same, but I
> > want to report the things I found.
>
> I just came up for air after about two solid days of working on this
> patch ... had not seen your me
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I don't think we should explicitly forbid it. I think it should be
> forbidden to close the outermost transaction inside a function (else the
> function would not be able to terminate correctly), but for levels
> before that one it'd be OK.
More specif
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Did I make a mistake by promoting subtransactions rather than
> savepoints?
No. We can implement savepoints on top of subtransactions, but not
vice versa. AFAICS the savepoint syntax is just a shorthand for
a constrained form of subtransaction --- esse
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I have a few other questions:
>
> > What is the procedure for moving tablespace directories?
>
> There is none.
>
> > However, pg_tablespace still has the old location.
>
> Yup. The *only* thing that pg_tablespace.spclocation is u
Tom Lane wrote:
> > Are we ripping out our initlocation code at the same time?
>
> Not done yet, but it's dead and should be removed as soon as a
> decent respect for the deceased permits ;-)
You want me to do the honors?
--
Bruce Momjian| http://candle.pha.pa.us
[E
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>>> Are we ripping out our initlocation code at the same time?
>>
>> Not done yet, but it's dead and should be removed as soon as a
>> decent respect for the deceased permits ;-)
> You want me to do the honors?
Nah, I'll get it. I want
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >>> Are we ripping out our initlocation code at the same time?
> >>
> >> Not done yet, but it's dead and should be removed as soon as a
> >> decent respect for the deceased permits ;-)
>
> > You want me to do the ho
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Somebody's got to fix oid2name and dbsize though. Bruce, you want
>> to catch those?
> Uh, how do they have to be fixed? Isn't the relfilenode unchanged? Do
> we just need to add tablespace lookups?
How useful will oid2name be if i
On Fri, 18 Jun 2004, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >>> Are we ripping out our initlocation code at the same time?
> >>
> >> Not done yet, but it's dead and should be removed as soon as a
> >> decent respect for the deceased permits ;-)
>
> > You
On Fri, 18 Jun 2004, Bruce Momjian wrote:
[snip]
> > TODO. You sound like a man who's expecting a
> > several-generations-polished facility when we only just committed
> > the first version today. I do not feel a need to have any of these
> > features in 7.5 ...
>
> I just need to know what to
Gavin Sherry wrote:
On Fri, 18 Jun 2004, Bruce Momjian wrote:
[snip]
TODO. You sound like a man who's expecting a
several-generations-polished facility when we only just committed
the first version today. I do not feel a need to have any of these
features in 7.5 ...
I just need to know
The other thing that I have been meaning to say in this thread is that I
don't like using COMMIT to mean subtransaction commit (vs. introducing a
new command for it) because of the following situation.
Lets say that I have a java method that takes a jdbc connection and this
code starts a trans
On Fri, 18 Jun 2004, Andreas Pflug wrote:
> Gavin Sherry wrote:
>
> >On Fri, 18 Jun 2004, Bruce Momjian wrote:
> >
> >[snip]
> >
> >
> >
> >>>TODO. You sound like a man who's expecting a
> >>>several-generations-polished facility when we only just committed
> >>>the first version today. I do not
Gavin Sherry <[EMAIL PROTECTED]> writes:
> On Fri, 18 Jun 2004, Bruce Momjian wrote:
>> * Allow reporting of which objects are in which tablespaces
> Do we need an information_schema.tablespaces view as well as an update to
> information_schema.{tables|indexes|...} ?
That would depend on your the
Gavin Sherry wrote:
On Fri, 18 Jun 2004, Andreas Pflug wrote:
Gavin Sherry wrote:
On Fri, 18 Jun 2004, Bruce Momjian wrote:
[snip]
TODO. You sound like a man who's expecting a
several-generations-polished facility when we only just committed
the first version today. I do not feel
On Sat, 19 Jun 2004, Andreas Pflug wrote:
[snip]
> >I don't think we should try and show all objects for a tablespace in
> >information_schema.
> >
> Agreed, information_schema is database specific. I was thinking about a
> pg_tablespace_contents(..) function anyway.
>
> >Being able to list all o
Barry Lind <[EMAIL PROTECTED]> writes:
> I like the functionality of nested transactions, I just think that there
> needs to be different commands other than BEGIN/COMMIT to work with
> them. So that there is no possiblity for misunderstanding what COMMIT
> really means.
There's something to b
Gavin Sherry wrote:
I would debate that.
Firstly, tablespaces aren't supported on windows yet.
Just a matter of time. And I'm talking of win32 workstations connecting
to *ix servers too.
Secondly, I'd think
that Unix users would be fine with a command line tool, especially one
that can connect to
Andreas Pflug <[EMAIL PROTECTED]> writes:
> IMHO checking objects in a tablespace is a routine administrative task,
> so it should be supported natively by the server without need of
> contribs.
I strongly disagree. Dropping a tablespace is not a routine activity,
and we don't have to have subm
Barry Lind wrote:
The other thing that I have been meaning to say in this thread is that I
don't like using COMMIT to mean subtransaction commit (vs. introducing a
new command for it) because of the following situation.
Lets say that I have a java method that takes a jdbc connection and this
c
Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > On Fri, 18 Jun 2004, Bruce Momjian wrote:
> >> * Allow reporting of which objects are in which tablespaces
This would have to be an external tool that connects to each database.
>
> > Do we need an information_schema.tablespaces view
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
IMHO checking objects in a tablespace is a routine administrative task,
so it should be supported natively by the server without need of
contribs.
I strongly disagree. Dropping a tablespace is not a routine activity,
Dropping c
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> As for the authentication-is-expensive issue, what of it? You *should*
>> have to authenticate yourself in order to look inside another person's
>> database. The sort of cross-database inspection being proposed here
>> would be a big
Andreas Pflug wrote:
> >>And for win user acceptance, a command line tool won't be
> >>sufficient either.
> >>
> >>
> >
> >This does not deserve a response.
> >
> >
>
> Well, that's not quite appropriate. A 'command line is enough for server
> maintenance' attitude won't attract win people
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Somebody's got to fix oid2name and dbsize though. Bruce, you want
> >> to catch those?
>
> > Uh, how do they have to be fixed? Isn't the relfilenode unchanged? Do
> > we just need to add tablespace lookups?
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> How useful will oid2name be if it doesn't understand about tablespaces?
>> I dunno how it ought to be changed, but surely it needs some thought.
> I assume we just need to add a tablespace display when run with no args,
> and a -s opti
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> How useful will oid2name be if it doesn't understand about tablespaces?
> >> I dunno how it ought to be changed, but surely it needs some thought.
>
> > I assume we just need to add a tablespace display when run w
Magnus, where are we on this refactoring process.
---
Magnus Hagander wrote:
> >> * Created function write_stderr(const char *fmt, ...), used
> >before elog
> >> can be used. This function will write to stderr on unix and o
Were are we on this?
---
Andreas Pflug wrote:
> Tom Lane wrote:
>
> >
> >This has got portability issues (fopen("ab"))
> >
> My doc says b is ignored on ansi systems, and recommends using it. Do
> you have other experience
Are we ripping out our initlocation code at the same time?
Not done yet, but it's dead and should be removed as soon as a
decent respect for the deceased permits ;-)
You want me to do the honors?
What about people upgrading from 7.4 databases that used database locations?
Chris
---
Patch applied. Thanks. I updated the comments at the top of win32.mak
too to document this new option.
I also made some changes so our Win32 native port can use threads too.
I need to modify the configure tests but for now the attached applied
patch will set up the groundwork for it. Mingw do
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> What about people upgrading from 7.4 databases that used database locations?
They'll get a nice warning:
regression=# create database foo location 'bar';
WARNING: LOCATION is not supported anymore
HINT: Consider using tablespaces instead.
CR
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I should think that the table-level display ought to show both the
>> relfilenode and tablespace OIDs for each table.
> For objects in the default tablespace, they don't show a tablespace oid,
> right? Where do we put it? A column th
OK, I have created the following diff to document the pgevent
installation instructions. However, you didn't send me a Makefile for
creating the DLL, and I am not sure how to do that. Would you send me a
`Makefile for src/bin/pgevent? Thanks.
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> I should think that the table-level display ought to show both the
> >> relfilenode and tablespace OIDs for each table.
>
> > For objects in the default tablespace, they don't show a tablespace oid,
> > right? Wh
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Well, I didn't use tablespaces here so the pg_tablespaces directory is
> empty, so I can't think of what the tablespace is.
You look in the pg_tablespace catalog for the row with that OID.
> Also, are we calling it pg_tablespaces (plural) rather than
>
37 matches
Mail list logo
