.
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: [EMAIL PROTECTED]
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs
Andrew Dunstan wrote:
Karel Zak wrote:
The problem with CSV is that it will correctly work with new protocol
only. Because old versions of clients are newline sensitive. And CSV
can contains newline in by quotation marks defined attributes:
John, Smith, The White House
1600 Pennsylvania
Hans-Jürgen Schönig wrote:
Karel Zak wrote:
Hi,
in TODO is item: * Allow dump/load of CSV format. I don't think
it's clean idea. Why CSV and why not something other? :-)
A why not allow to users full control of the format by they own
function. It means something like:
COPY tablename [ (
Tom Lane wrote:
Karel Zak [EMAIL PROTECTED] writes:
The formatting function API can be pretty simple:
text *my_copy_format(text *attrdata, int direction,
int nattrs, int attr, oid attrtype, oid relation)
This seems like it could only reasonably be implemented as a C function.
I
Lamar Owen wrote:
On Saturday 13 March 2004 10:36 am, Fernando Nasser wrote:
The problem is that sysloging has more overhead than a plain append to a
file. There are some very strict response time AppServer applications
where we want to keep this things out of the picture.
Well, I have
Lamar Owen wrote:
On Saturday 13 March 2004 01:00 pm, Fernando Nasser wrote:
There are some applicatons which run in servers with very strict
response times and any syscall, network packet that can be saved counts.
Ok, what about pipe overhead? If we're gong to split hairs, let's split all
Bruno Wolff III wrote:
On Fri, Mar 12, 2004 at 15:19:29 -0500,
Fernando Nasser [EMAIL PROTECTED] wrote:
Bruno Wolff III wrote:
I can see their problem with making a dependency to all of apache or
including
multilog in their distribution. But they probably could include something
that is only
.
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: [EMAIL PROTECTED]
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org
Robert Treat wrote:
Different postmasters = different conf files. Just set your syslog_facility
and/or your syslog_ident differently and it should be pretty easy to seperate
the logs. Actually, now that I have started using syslog fairly regularly, I
find it hard to believe it would be worth
someone could make some measurements to desmistify the performance
impact of syslog. There is this generalized belief in IS departments
that should minimize it. Perhaps is an old fud that is not anylonger true.
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: [EMAIL PROTECTED
Patrick Welche wrote:
On Sat, Mar 13, 2004 at 10:36:23AM -0500, Fernando Nasser wrote:
Lamar Owen wrote:
Ok, riddle me this:
If I have PostgreSQL set to log to syslog facility LOCAL0, and a
local0.none on /var/log/messages and local0.* to /var/log/pgsql (assuming
only one postmaster
Tom Lane wrote:
Fernando Nasser [EMAIL PROTECTED] writes:
Please remind me again why the postmaster cannot close and open the log
file when it receives a SIGHUP (to re-read configuration)?
(a) Because it never opened it in the first place --- the log file is
whatever was passed as stderr.
(b
Bruno Wolff III wrote:
I can see their problem with making a dependency to all of apache or including
multilog in their distribution. But they probably could include something
that is only a logger either using some project that is only a logger or
splitting out the logger that is bundled with
Hi Lamar,
Lamar Owen wrote:
On Friday 12 March 2004 09:24 am, Fernando Nasser wrote:
I don't really care on how its done, but IMO an enterprise class
database must be able to do log rotation. Logging to Syslog is not an
option (specially with our verbosity) -- users must be able to use flat
Hi,
Please remind me again why the postmaster cannot close and open the log
file when it receives a SIGHUP (to re-read configuration)? This was
discussed before but I cannot remember if and why this was not possible
or if the arguments are still valid after -l was added.
If this was possible
used, and not some hardcoded value).
As you see, these goals can be achieved without any changes in the
postgresql community sources.
Regards to all,
Fernando
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: [EMAIL PROTECTED]
2323 Yonge Street, Suite #300
Toronto, Ontario M4P
always document that it is for machine consumption, of
course.
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: [EMAIL PROTECTED]
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
---(end of broadcast)---
TIP 2: you can get
. The only fields that the
program need to know about (like name and group) are not likely to change.
No big deal though.
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: [EMAIL PROTECTED]
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
---(end
] so that your
message can get through to the mailing list cleanly
--
Fernando Nasser
Red Hat - Toronto E-Mail: [EMAIL PROTECTED]
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
---(end of broadcast)---
TIP 4
the column and table involved so it will be easier to identify the two you have
to get rid of.
Regards,
Fernando
--
Fernando Nasser
Red Hat - Toronto E-Mail: [EMAIL PROTECTED]
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
---(end
Bruce Momjian wrote:
I will update for 7.4 now. Too late for 7.3 clearly.
Bruce, why is it too late?
Most (all) will upgrade to 7.3.1 anyway, so it is a chance to get things right.
--
Fernando Nasser
Red Hat - Toronto E-Mail: [EMAIL PROTECTED]
2323 Yonge Street
schemas to be dumped
it would be easy to restore it as another or even move it to another
database. And one could dump only the schema or schema+data, as needed.
Of course, dependencies would have to be handled as objects can refer to
objects in other schemas.
--
Fernando Nasser
Red Hat Canada Ltd
to them _there_? We just need to make sure
we have schema qualified references to the sequences and types.
Indexes, triggers (and constraints), toast tables etc. are related to
just one table so they can migrate together, I think.
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail
;-)
Regards,
Fernando
Joe Conway wrote:
Fernando Nasser wrote:
Why not just leave the sequence and types in the original schema and
make sure the table refers to them _there_? We just need to make sure
we have schema qualified references to the sequences and types.
Well, the type entry
specific description.
Note that the standard allows for implementation-defined codes, so we can have
our own CC classes and all the SSS subclasses that we need.
--
Fernando Nasser
Red Hat - Toronto E-Mail: [EMAIL PROTECTED]
2323 Yonge Street, Suite #300
Toronto, Ontario
)
{
AlterTableDoSomething(childrel,...);
}
--
Fernando Nasser
Red Hat - Toronto E-Mail: [EMAIL PROTECTED]
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
---(end of broadcast)---
TIP 3: if posting/reading through Usenet
are not part of Core SQL'99, but I would not leave them out).
Regards,
Fernando
--
Fernando Nasser
Red Hat - Toronto E-Mail: [EMAIL PROTECTED]
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
---(end of broadcast
if indices extensions were involved anyway).
I would keep operators database-wide.
--
Fernando Nasser
Red Hat - Toronto E-Mail: [EMAIL PROTECTED]
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
---(end of broadcast
Hiroshi Inoue wrote:
Fernando Nasser wrote:
As most things in the SQL standard, you have to collect information
from several places and add it together.
Look at 4.20, 11.1 and specially at the rules for
schema qualified name.
Then think a little bit about scenarios, trying
scenarios, trying to apply the rules.
It is a pain, but there is no other way.
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: [EMAIL PROTECTED]
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
---(end of broadcast
can issue
and error if a grant is for something that is not an object in the
schema being created.
Regards,
Fernando
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: [EMAIL PROTECTED]
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
---(end
and UDTs where each schema has a SQL-path for
searching those (the implied schema must always be in it though).
There must be an implementation-defined default for this SQL-path
(but the implied schema must also be in it).
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: [EMAIL
and create their databases without schemas as
before.
3) If the DBA is careful enough, she/he can convert his/her database to
use schemas incrementally.
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: [EMAIL PROTECTED]
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
that are not their user id can save some typing. ;-)
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: [EMAIL PROTECTED]
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
---(end of broadcast)---
TIP 3: if posting/reading through Usenet
Tom Lane wrote:
I've been vacillating about whether to choose another name for the
public namespace to avoid the need for quotes here. I can't think
of another good name :-(
For the special schemas, we have pg_catalog, (pg_temp, pg_toast ?),
so pg_public could do the trick.
--
Fernando
names.
Once you redo your database to use schemas, or even while you are
converting it, there should not be tables with the same name in both
places.
Anyway, as Tom said, you can change the search order if you prefer.
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: [EMAIL
to public, common or something else.
It is a PostgreSQL concept anyway.
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: [EMAIL PROTECTED]
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
---(end of broadcast)---
TIP 1
Tom Lane wrote:
Fernando Nasser [EMAIL PROTECTED] writes:
Tom Lane wrote:
I've been vacillating about whether to choose another name for the
public namespace to avoid the need for quotes here. I can't think
of another good name :-(
For the special schemas, we have pg_catalog
Tom Lane wrote:
Fernando Nasser [EMAIL PROTECTED] writes:
Tom Lane wrote:
Actually that was my initial choice of name, but I changed my mind
later. The reason is that the dbadmin should be able to restrict or
even delete the public namespace if his usage plans for the database
don't
[int4] [NOT NULL] [DEFAULT 32];
ALTER TABLE blah ALTER [COLUMN] col [int8] [NULL] [DEFAULT 32];
maybe even [DEFAULT NULL] to drop the default :-)
I like this one. I would not make COLUMN optional though.
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: [EMAIL PROTECTED]
2323
for a domain.
(In fact, I'd be inclined to set things up so that it's impossible to
store domain type OIDs in pg_proc or pg_operator, thus saving the time
of doing getBaseType on one side of the match.) Thoughts?
IMHO this is the right thing to do.
--
Fernando Nasser
Red Hat - Toronto
.
--
Fernando Nasser
Red Hat - Toronto E-Mail: [EMAIL PROTECTED]
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Tom Lane wrote:
Any thoughts?
As we are talking about CAST,
if one CASTs to a domain, SQL99 says we have to check the constraints
and issue a integrity constraint violation if appropriate (6.22, GR 21).
--
Fernando Nasser
Red Hat - Toronto E-Mail: [EMAIL PROTECTED
Well,
Someone just dropped the DROP DATABASE statement rules right in the
middle of the CREATE DATABASE production rules!!!
Fernando
Fernando Nasser wrote:
The OWNER production rules added to DROP DATABASE:
DropdbStmt: DROP DATABASE database_name
takes the
last bit of the name and ignores all the qualifiers...
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: [EMAIL PROTECTED]
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
---(end of broadcast)---
TIP 1
easily take INSERT bar.foo (bar.foo.col) but the
above one is trouble.
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: [EMAIL PROTECTED]
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
---(end of broadcast)---
TIP 6
Vince Vielhaber wrote:
On Thu, 14 Mar 2002, Rod Taylor wrote:
Out of curiosity, does SyBase allow you to qualify it with
schema.table.column?
Just tried it... Yes.
What if you give it a bogus schema name? Does it error out or just
ignore it?
--
Fernando Nasser
Red Hat Canada
/fnasser/DEVO/pgsql/pgsql/src/backend/parser/gram.y:3205:
warning: assignment from incompatible pointer type
(...)/pgsql/src/backend/parser/gram.y:3209: warning: assignment from
incompatible pointer type
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: [EMAIL PROTECTED]
2323
?)
The wire protocol will always handle the (tableoid) long form,
references will always store
the long form... The OID32 would exist only to allow people to save
space in tables that need
OIDs but not the 64 bit version.
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: [EMAIL
.
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: [EMAIL PROTECTED]
2323 Yonge Street, Suite #300
--
-- Clean up
--
==
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: [EMAIL PROTECTED]
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
---(end of broadcast
Please disregard this. This message was held by Majordomo for a couple
of days and I have already resent it.
Tom Lane has already solved my problem (I had a miscompiled version of
bison in my machine).
Regards to all,
Fernando
Fernando Nasser wrote:
Is anyone else seeing this?
I have
Tom Lane wrote:
Fernando Nasser [EMAIL PROTECTED] writes:
Is anyone else seeing this?
No.
I have the current CVS sources and make check ends up with one
failure. My regression.diffs shows:
I think you must have built gram.c with a broken bison or yacc. What
exactly
--
-- Clean up
--
==
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: [EMAIL PROTECTED]
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
---(end of broadcast
54 matches
Mail list logo
