Tom Lane wrote:
Okay, I don't want to force an initdb just for this either. But if we
do one for other reasons, it's toast.
I don't see why an initdb is required: if we want to remove it, we can
replace the function's implementation with elog(ERROR, "this function
has been removed"), or the like
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I see it in the SGML docs:
> Warning: to_char(interval,
> text)
> is deprecated and should not be used in newly-written code. It will be removed
> in the next version.
> I suppose that is enough warning. Is it fair to remove things during
> b
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Darcy Buskermolen wrote:
> >>> * remove to_char(interval) if we initdb or mention removal
> >>
> >> I vote just to mention it's removal at this time,
>
> > Agreed. Done.
>
> While I don't care that much one way or the other --- wha
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Darcy Buskermolen wrote:
>>> * remove to_char(interval) if we initdb or mention removal
>>
>> I vote just to mention it's removal at this time,
> Agreed. Done.
While I don't care that much one way or the other --- what is the
difference between this a
Agreed. Done.
---
Darcy Buskermolen wrote:
> On August 20, 2004 01:28 pm, Bruce Momjian wrote:
> >P O S T G R E S Q L
> >
> > 8 . 0 O P E NI T E M S
> > * deter
I didn't like the Solaris bug mention in pg_hba.conf. It seemed like
the wrong place:
+ # Note: On some Solaris systems, an IP-MASK of 255.255.255.255 is known not to work.
+ # The corresponding CIDR-MASK of /32 does work.
I have removed it. Should we put something in the docs instead, or add
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> "MySQL does, however, support the advanced feature of data partitioning
>> within a database. PostgreSQL does not."
> Well there is table partitioning and then there is tablespaces.
> PostgreSQL 8 supports table spaces but not table partitioning.
Gaetano Mendola <[EMAIL PROTECTED]> writes:
>> I think we should just call gettimeofday() at postmaster start and store
>> it somewhere.
> Isn't the shared memory a good place ?
Depends. Do you want to reset it during a backend-crash-recovery cycle?
You'll have to, if it's only stored in shared
Or this one:
"MySQL does, however, support the advanced feature of data partitioning
within a database. PostgreSQL does not."
Isn't that what tablespaces are all about?
Well there is table partitioning and then there is tablespaces.
PostgreSQL 8 supports table spaces but not table partitioning.
On Sat, Aug 21, 2004 at 01:15:29AM +0200, Gaetano Mendola wrote:
> http://www.devx.com/dbzone/Article/20743
>
> I notice on page 2:
>
> "New versions of PostgreSQL support standard row-level
> locking as an option, but MVCC is the preferred method"
>
> What this does mean ?
Or this one:
"MyS
Hi all,
reading this article:
http://www.devx.com/dbzone/Article/20743
I notice on page 2:
"New versions of PostgreSQL support standard row-level
locking as an option, but MVCC is the preferred method"
What this does mean ?
Regards
Gaetano Mendola
---(end of broadcast)-
Bruce Momjian wrote:
Andreas Pflug wrote:
Guess what I just implemented...
pg_postmaster_starttime() RETURNS timestamp, currently implemented in
the admin module for win32 using GetProcessTimes(PostmasterHandle).
What's the equivalent for posix? Interpreting popen("ps...") might get
messy.
I
On August 20, 2004 01:28 pm, Bruce Momjian wrote:
>P O S T G R E S Q L
>
> 8 . 0 O P E NI T E M S
> * determine proper crash recovery/logging for pg_subtrans
> * remove to_char(interval) if we initdb or mention removal
I vote just to m
Andreas Pflug wrote:
> Bruce Momjian wrote:
>
> >
> > I think we should just call gettimeofday() at postmaster start and store
> > it somewhere.
>
> No objections, but that's probably not done in 8.0 any more, right?
Right.
--
Bruce Momjian| http://candle.pha.pa.us
Bruce Momjian wrote:
I think we should just call gettimeofday() at postmaster start and store
it somewhere.
No objections, but that's probably not done in 8.0 any more, right?
Regards,
Andreas
---(end of broadcast)---
TIP 2: you can get off all lists
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am inclined to agree. ALTER INDEX is an operation that will happen
> quite often, but I don't think ALTER SCHEMA will be as frequent, and the
> given solution doesn't address the two needs of moving the entire schema
> or just future object creation.
P O S T G R E S Q L
8 . 0 O P E NI T E M S
Current version at ftp://momjian.postgresql.org/pub/postgresql/open_items.
Changes
---
* Win32
o add binary version stamps?
o fix signal-safe socket handler for SSL
Patch applied. Thanks.
---
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>
> >Andrew Dunstan <[EMAIL PROTECTED]> writes:
> >
> >
> >>At this stage of the game I would just change pg_hba.conf.sample to use
> >>'127.0.0.
This has been saved for the 8.1 release:
http:/momjian.postgresql.org/cgi-bin/pgpatches2
---
Richard van den Berg wrote:
> Since I needed this feature badly, I added the -n / --schema switch to
> pg_restore. It res
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Fri, Aug 20, 2004 at 01:36:39PM -0400, Tom Lane wrote:
>> I thought from the
>> beginning that the slru layer underneath pg_clog was bad from the point
>> of view of obfuscating the code, because it forced an awkward division
>> of labor between clog.
Marc G. Fournier wrote:
> On Fri, 20 Aug 2004, Bruce Momjian wrote:
>
> > Would people like this applied to 8.0? It addresses another of the
> > tablespace deficiency.
>
> This is an extension of tablespaces, and is not required to fix a bug ...
> therefore, it is a feature, and not eligible fo
Patch applied. Thanks.
---
Philip Warner wrote:
> At 01:32 AM 16/08/2004, Tom Lane wrote:
> >It'd be substantially *more* helpful if it reported the failing command.
>
> They are two different problems; the TOC entry is i
On Fri, 20 Aug 2004, Bruce Momjian wrote:
Would people like this applied to 8.0? It addresses another of the
tablespace deficiency.
This is an extension of tablespaces, and is not required to fix a bug ...
therefore, it is a feature, and not eligible for inclusion at this point
in the developmen
On Fri, Aug 20, 2004 at 01:36:39PM -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > On Tue, Aug 10, 2004 at 12:24:06PM -0400, Tom Lane wrote:
> >> It may be that we do not care because pg_subtrans doesn't have to be
> >> valid after a crash, but I haven't seen any proof of th
Would people like this applied to 8.0? It addresses another of the
tablespace deficiency.
One item of concern is that it moves the default location for new items
created, and does not move items already created in the tablespace
itself. This conflicts with ALTER TABLE/INDEX which moves the actu
Andreas Pflug wrote:
> Robert Treat wrote:
>
> >
> > If we do add this function, I guarantee you that you'll see it added to
> > phppgadmin and pgadmin, because it helps make these remote
> > administration tools more complete.
>
> :-)
> Guess what I just implemented...
>
> pg_postmaster_start
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Tue, Aug 10, 2004 at 12:24:06PM -0400, Tom Lane wrote:
>> It may be that we do not care because pg_subtrans doesn't have to be
>> valid after a crash, but I haven't seen any proof of that theory.
> The whole point of the subtrans info is to be availa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I all,
I was able to create the RPM for RH 2.1 AS
using the SRPMS found at
ftp://ftp.postgresql.org/pub/binary/v7.4.5/srpms/redhat-9/
rpmbuild --rebuild --define 'python 0' postgresql-7.4.5-1PGDG.src.rpm
You can find the RPMs at:
http://mendola.no-ip.co
Robert Treat wrote:
If we do add this function, I guarantee you that you'll see it added to
phppgadmin and pgadmin, because it helps make these remote
administration tools more complete.
:-)
Guess what I just implemented...
pg_postmaster_starttime() RETURNS timestamp, currently implemented in
the
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Thu, 19 Aug 2004, Tom Lane wrote:
>> Almost there, but you didn't pick up my regression test patches :-(
> Fixed ...
Ok, the re-re-wrap looks good AFAICS.
> Now, what about Robert/Chris' comments about the potential changes in
> error messages
I am still seeing random regression test failures on my SMP BSD/OS
machine. It basically happens when doing 'gmake check'.
I have tried running repeated tests and can't get it to reproduce, but
when checking patches it has happened perhaps once a week for the past
six weeks. It happens once and
On Fri, 2004-08-20 at 05:41, Gaetano Mendola wrote:
> Tom Lane wrote:
>
> > I'd like to see more than one person requesting this (and with solider
> > rationales) before it gets added to TODO. If I wanted to be picky I
> > would suggest that knowledge of the server start time might be useful
>
Hi,
On Thu, 19 Aug 2004, Marc G. Fournier wrote:
> Devrim/David ... I'm doing a force sync of the ftp site from developer ->
> ftp right now, so all the bundles should be there for you ... the SRPMs
> are done for 7.4.5, are you going to do similiar with the 7.2.5 and 7.3.7
> distros?
Are 7.
ivan wrote:
hi,
i have a problem with selecting function :
db=# select auxilium.exists('arx.mods', 'r');
exists
t
(1 row)
db=# select exists('arx.mods', 'r');
ERROR: syntax error at or near "'arx.mods'" at character 15
I believe the problem here is that exists is a reserved word (as in
hi,
i have a problem with selecting function :
db=# select auxilium.exists('arx.mods', 'r');
exists
t
(1 row)
db=# select exists('arx.mods', 'r');
ERROR: syntax error at or near "'arx.mods'" at character 15
db=# show search_path;
search_path
---
auxi
Tom Lane wrote:
> I'd like to see more than one person requesting this (and with solider
rationales) before it gets added to TODO. If I wanted to be picky I
would suggest that knowledge of the server start time might be useful
information to an attacker. It would for instance narrow down the
num
Richard Huxton wrote:
Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
Does anyone have any 'benefits' to implementing such a thing that we
can list? The cons appear to be easy, what about pros?
That's exactly what's bugging me --- I have not seen any particularly
strong defense of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christopher Kings-Lynne wrote:
|> It seems that there is no way to know the postgres
|> uptime, a sort of uptime() function could be usefull.
|> I had recently the necessity of detect a node fail over,
|> and the only way I can do it with a SQL connecti
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
Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
Does anyone have any 'benefits' to implementing such a thing that we can
list? The cons appear to be easy, what about pros?
That's exactly what's bugging me --- I have not seen any particularly
strong defense of why we *should* have
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
43 matches
Mail list logo
