At 03:15 PM 23/08/2004, Tom Lane wrote:
I thought the idea was for pg_dump to emit something like
SET magic_tablespace_variable = some_ts;
CREATE TABLE foo (columns...);
rather than
CREATE TABLE foo (columns...) TABLESPACE some_ts;
the point being...
Yep.
I am quite unsure
Philip Warner <[EMAIL PROTECTED]> writes:
> So, if you do make the changes, will the schema definition be affected by
> those changes, or do you expect the tablespace to be embedded in the CREATE
> SCHEMA command?
I thought the idea was for pg_dump to emit something like
SET magic_table
At 02:28 PM 23/08/2004, Tom Lane wrote:
There's been some talk of that, but AFAICS it's not related to an ALTER
SCHEMA SET [DEFAULT] TABLESPACE command.
So, if you do make the changes, will the schema definition be affected by
those changes, or do you expect the tablespace to be embedded in the CR
On Sun, 22 Aug 2004, Peter Eisentraut wrote:
> To me, this seems completely wrong-headed. Data types should be defined
> by what operations you can do on them, not by what output format they
> have.
I totally agree, lets get rid of money all together.
If not, what makes money so special? Do w
Philip Warner <[EMAIL PROTECTED]> writes:
> At 01:48 PM 23/08/2004, Marc G. Fournier wrote:
>> Won't the dump/restore "store" a "CREATE SCHEMA" onto the new
>> tablespace? Why would a dump/restore issue an ALTER SCHEMA part way through?
> We've had the same problem with CREATE TABLE statements.
At 01:48 PM 23/08/2004, Marc G. Fournier wrote:
Won't the dump/restore "store" a "CREATE SCHEMA" onto the new
tablespace? Why would a dump/restore issue an ALTER SCHEMA part way through?
My *belief* is that if the tablespace does not exist, then the restore
(which creates the schema and refers t
On Mon, 23 Aug 2004, Philip Warner wrote:
At 01:04 PM 23/08/2004, Marc G. Fournier wrote:
not having ALTER SCHEMA to move tablespaces is not a bug
But it does make pg_dump/restore more inclined to fail, so increases the
incidence of another bug, which can not be fixed without a global SET
DEFAULT
At 01:04 PM 23/08/2004, Marc G. Fournier wrote:
not having ALTER SCHEMA to move tablespaces is not a bug
But it does make pg_dump/restore more inclined to fail, so increases the
incidence of another bug, which can not be fixed without a global SET
DEFAULT TABLESPACE or an ALTER SCHEMA.
On Mon, 23 Aug 2004, Christopher Kings-Lynne wrote:
What the hey? For how long is that going to be our excuse for sucking?
No wonder everyone thinks we're newbie unfriendly and hard to use...
We are in a beta freeze ... not having ALTER SCHEMA to move tablespaces is
not a bug, and is not appropr
On Sunday 22 August 2004 21:34, Marc G. Fournier wrote:
> On Mon, 23 Aug 2004, Christopher Kings-Lynne wrote:
> >>> 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 development cycle
What the hey? For how long is that going to be our excuse for
sucking? No wonder everyone thinks we're newbie unfriendly and hard
to use...
We are in a beta freeze ... not having ALTER SCHEMA to move tablespaces
is not a bug, and is not appropriate for adding during a beta freeze ...
once 8.0
On Mon, 23 Aug 2004, Christopher Kings-Lynne wrote:
It will be 5 minutes before someone who has created a schema in 8.0 and
then will want to make it have a different default - there's no way they
can do it...
If they just created the schema, then a dump/reload would fix it ...
What the hey? For
On Sunday 22 August 2004 07:53, Mahmoud Taghizadeh wrote:
> 1. we want to translate some postgreSql documents
> (FAQ, tutorial for start). I want to know who is
> responsible for this part in postgreSQL (we are from
> IRAN)
>
If you translate the FAQ, make sure it is the html version
(http://deve
It will be 5 minutes before someone who has created a schema in 8.0
and then will want to make it have a different default - there's no
way they can do it...
If they just created the schema, then a dump/reload would fix it ...
What the hey? For how long is that going to be our excuse for sucking
On Mon, 23 Aug 2004, Christopher Kings-Lynne wrote:
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 development cycle ...
I am inclined to agree. ALTER INDEX is an operation that will happe
Although plans for a more general cleanup of contrib/ will have to go
back on the shelf for a future release, the core committee is still of
the opinion that it'd be wise to remove rserv in 8.0.
Also we really should probably rip out Tsearch (not Tsearc2) as well.
Eventually yes, but I'm not too
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 development cycle ...
I am inclined to agree. ALTER INDEX is an operation that will happen
quite often, but I don't think ALTER SCHEMA will b
I'd like it applied, but change it to 'SET DEFAULT TABLESPACE' perhaps...?
Chris
Bruce Momjian wrote:
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 a
Mahmoud Taghizadeh wrote:
3. we are planning to add locale per column for
postgreSQL, but I found that you had said its
impossible. am I right? do you have any paper about
it?
One of the ways to solve this is to have a special data type for this
purpose. Check out the mssqlext project on pgfou
Tom Lane <[EMAIL PROTECTED]> writes:
> Oliver Elphick <[EMAIL PROTECTED]> writes:
> > It seems to me a monetary type is a complex type consisting of currency
> > code and amount -- but you couldn't sum mixed currencies. Or else it is
> > limited to the currency of the locale, which doesn't seem
On P, 2004-08-22 at 23:07, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> We keep hoping someone will step up to the plate and rewrite it,
> >> instead. Per previous discussion, the type really ought to be a thin
> >> layer over "numeric", with most likely n
On Sun, 22 Aug 2004 13:29:14 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> Are you aware that the monetary type is deprecated and is going to be
> dropped entirely pretty soon? I would not recommend that you spend
> any time on it, unless you want to commit to doing a wholesale
> rewrite. Store your
Tom Lane wrote:
> The idea behind the money type is to format per the lc_monetary
> locale setting, which seems perfectly reasonable to me.
To me, this seems completely wrong-headed. Data types should be defined
by what operations you can do on them, not by what output format they
have. With t
Oliver Elphick <[EMAIL PROTECTED]> writes:
> It seems to me a monetary type is a complex type consisting of currency
> code and amount -- but you couldn't sum mixed currencies. Or else it is
> limited to the currency of the locale, which doesn't seem particularly
> useful.
In a former lifetime I
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> We keep hoping someone will step up to the plate and rewrite it,
>> instead. Per previous discussion, the type really ought to be a thin
>> layer over "numeric", with most likely no operations of its own
>> except I/O conversion.
>
On Sun, 2004-08-22 at 20:40, Tom Lane wrote:
> Mike Mascari <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Are you aware that the monetary type is deprecated and is going to be
> >> dropped entirely pretty soon?
>
> > What's taking so long? ;-)
>
> We keep hoping someone will step up to the
Tom Lane wrote:
> We keep hoping someone will step up to the plate and rewrite it,
> instead. Per previous discussion, the type really ought to be a thin
> layer over "numeric", with most likely no operations of its own
> except I/O conversion.
And what would it do with it? Add a currency symbol?
Mike Mascari <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Are you aware that the monetary type is deprecated and is going to be
>> dropped entirely pretty soon?
> What's taking so long? ;-)
We keep hoping someone will step up to the plate and rewrite it, instead.
Per previous discussion, the
Tom Lane wrote:
Mahmoud Taghizadeh <[EMAIL PROTECTED]> writes:
a dirty method to fix this bug is to replace following
Are you aware that the monetary type is deprecated and is going to be
dropped entirely pretty soon?
What's taking so long? ;-)
Mike Mascari
---(end of broad
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Although plans for a more general cleanup of contrib/ will have to go
>> back on the shelf for a future release, the core committee is still of
>> the opinion that it'd be wise to remove rserv in 8.0.
> Also we really should probab
Tom Lane wrote:
Although plans for a more general cleanup of contrib/ will have to go
back on the shelf for a future release, the core committee is still of
the opinion that it'd be wise to remove rserv in 8.0. Anyone who
really wants it will always be able to get it from our CVS archives or
old r
There has been some previous discussion of removing the contrib/rserv
module, on the grounds that (1) it's horribly obsolete and unmaintained,
and (2) its presence in the core distribution may mislead users into not
considering the newer better replication solutions available elsewhere
(erserver, s
Andrew Dunstan wrote:
> Tom Lane said:
> > "Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> >> Since our defaults don't use old-style masks any more, I would be
> >> tempted to remove the column labels for IP-ADDRESS and IP-MASK, and
> >> instead put in a single heading of IP-ADDRESS/CIDR-MASK.
> >
>
Tom Lane said:
> "Andrew Dunstan" <[EMAIL PROTECTED]> writes:
>> Since our defaults don't use old-style masks any more, I would be
>> tempted to remove the column labels for IP-ADDRESS and IP-MASK, and
>> instead put in a single heading of IP-ADDRESS/CIDR-MASK.
>
> I don't know why there is any deb
Mahmoud Taghizadeh <[EMAIL PROTECTED]> writes:
> a dirty method to fix this bug is to replace following
> line
> if (isdigit((unsigned char) *s) && dec < fpoint )
> with
> if (isdigit((unsigned char) *s) && ((dec < fpoint) ||
> fpoint == 0))
This patch is wrong. Something involving "!seen_dot |
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> Since our defaults don't use old-style masks any more, I would be tempted to
> remove the column labels for IP-ADDRESS and IP-MASK, and instead put in a
> single heading of IP-ADDRESS/CIDR-MASK.
I don't know why there is any debate about this. When I
On Sun, 22 Aug 2004, Mahmoud Taghizadeh wrote:
> 3. we are planning to add locale per column for
> postgreSQL, but I found that you had said its
> impossible. am I right? do you have any paper about
> it?
>
> 4. If I want to add collate order for postgreSQL what
> should I do? is there any guid
Mahmoud Taghizadeh wrote:
> 1. we want to translate some postgreSql documents
> (FAQ, tutorial for start). I want to know who is
> responsible for this part in postgreSQL (we are from
> IRAN)
You are. :)
> 2. there is a little bug about our monetary in
> postgreSQL (locale), if I want to fix it w
Dear All,
we are envolving in a national project and we want to
add our locale support in postgreSQL. we found that
the postgreSQL does not support locale very well. we
want to start our work by translation some part of
postgreSQL documents. then fix some little bug about
our locale in postgreSQL
I found a little bug in monetary function of
postgresql function cash_in in file cash.c
the problem is that when I run
set lc_monetary to "fa_IR.UTF8"
and try to insert a value to a field with type of
money, I got the following error:
"invalid input syntax for type money: "1000"
at the same time
Hi list,
I asked both these questions on the cygwin list, but as I've started to
look into the native port as well, and as I didn't get any answer there,
I would appreciate any answer here as well.
I'm trying to compile an external library for use as a postgres
extension. The project is availab
Bruce Momjian said:
> Joshua D. Drake wrote:
>> Bruce Momjian wrote:
>>
>> >We have an IP-MASK column in pg_hba.conf. Now that we are using CIDR
>> >addresses by default, should we remove the column label?
>> >
>> >
>> >
>> I would mark it optional.
>
> We could do that, but we could use the space
42 matches
Mail list logo
