What use is the -X flag to pg_dump. The code say that if one add a setting
feature to -X then there should also be a flag --feature. So we have
for example:
-X disable-triggers
and
--disable-triggers
If all the -X flags come in a long form as well, then what use is the -X
at all? Why
Robert Lor wrote:
Bruce,
The binary was compiled in 32bit mode using Sun Studio compiler, and we
plan to do 64bit soon. Can you point me to the patch? We can certainly
test it!
Download CVS HEAD and give it a try. The file that was created for the
port is
unsubscribe
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Dennis Bjorklund wrote:
What use is the -X flag to pg_dump. The code say that if one add a setting
feature to -X then there should also be a flag --feature. So we have
for example:
-X disable-triggers
and
--disable-triggers
If all the -X flags come in a long form as well,
If we want to save the SQL statement for some database objects(table, view,
etc.),
the backend will see the same problem. Here is an example.
create table s(sno int, sname char(10)); select 1;
I recall that some DBMS will store the statement for table s like this:
create table s(sno int,
I think we should pay attention to the sematic of table privs and column
privs.
Here is some examples.
1. role1 GRANT table priviledge SELECT on table S to role2.
role1 REVOKE column priviledge SELECT on column S(SNO) from role2.
2. deal with circles in GRANT graph.
kevin brintnall [EMAIL
Andrew - Supernews [EMAIL PROTECTED] writes:
The spec is quite explicit that inet_pton is not expected to accept the
abbreviated forms or any non-decimal values.
Hum. That distinctly doesn't match my memory but it seems you're right. The
spec mandates inet_ntoa and inet_addr support it but not
On Jan 25, 2006, at 9:29 AM, Bruce Momjian wrote:
Tom Lane wrote:
Greg Stark [EMAIL PROTECTED] writes:
I wonder if this would be an opportunity to fix Postgres's
handling of
addresses like '10.1'.
You've mistaken this for a proposal to change the I/O behavior, which
it is specifically
Michael Fuhr wrote:
Rollback Mountain
A raw, powerful story of two young transactions, one serializable
and the other read-committed, who meet in the summer of 2005 updating
tables in the harsh, high-volume environment of a contemporary
online trading system and form an unorthodox yet
I am not sure what to do on this. Right now we have a one-line test:
AC_REPLACE_FUNCS([getaddrinfo])
To test for a macro we are going to need to add include netdb.h, and the
LINK test below is overkill. I am thinking we should just hard-code in
HAVE_GETADDRINFO for the True64 platform;
On Wed, Jan 25, 2006 at 4:46 pm, in message
[EMAIL PROTECTED], Kevin Grittner
[EMAIL PROTECTED] wrote:
(2) There should probably be some tests added to exercise these
options.
Attached is a patch to address this one. Note that until psql is
fixed, this test will fail. I manually
Bruce Momjian pgman@candle.pha.pa.us writes:
I am not sure what to do on this. Right now we have a one-line test:
AC_REPLACE_FUNCS([getaddrinfo])
To test for a macro we are going to need to add include netdb.h, and the
LINK test below is overkill. I am thinking we should just hard-code
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
I am not sure what to do on this. Right now we have a one-line test:
AC_REPLACE_FUNCS([getaddrinfo])
To test for a macro we are going to need to add include netdb.h, and the
LINK test below is overkill. I am thinking we
Bruce Momjian pgman@candle.pha.pa.us writes:
I have the answer. Tru64 netdb.h has:
#if defined (_SOCKADDR_LEN) || defined (_XOPEN_SOURCE_EXTENDED)
#define getaddrinfo ngetaddrinfo
#else
#define getaddrinfo ogetaddrinfo
#endif
Seems like the same method we use
Dennis Bjorklund wrote:
If all the -X flags come in a long form as well, then what use is the
-X at all? Why would one want to use -X disable-triggers instead of
--disable-triggers ?
This was added before we had portable long options. I suppose we could
phase it out.
--
Peter Eisentraut
Peter Eisentraut wrote:
Dennis Bjorklund wrote:
If all the -X flags come in a long form as well, then what use is the
-X at all? Why would one want to use -X disable-triggers instead of
--disable-triggers ?
This was added before we had portable long options. I suppose we could
Tom Lane wrote:
Without the flag, it's okay for cidr-to-inet to be a
binary-compatible (no function) conversion. However, inet-to-cidr
has to either zero out bits to the right of the netmask, or error out
if any are set. Joachim Wieland posted a patch that makes the
coercion function just
Peter Eisentraut wrote:
Dennis Bjorklund wrote:
If all the -X flags come in a long form as well, then what use is the
-X at all? Why would one want to use -X disable-triggers instead of
--disable-triggers ?
This was added before we had portable long options. I suppose we could
phase
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
Without the flag, it's okay for cidr-to-inet to be a
binary-compatible (no function) conversion. However, inet-to-cidr
has to either zero out bits to the right of the netmask, or error out
if any are set. Joachim Wieland posted a
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
Without the flag, it's okay for cidr-to-inet to be a
binary-compatible (no function) conversion. However, inet-to-cidr
has to either zero out bits to the right of the netmask, or error out
if any are set.
On Thu, Jan 26, 2006 at 11:36:15AM +0100, Peter Eisentraut wrote:
James William Pye wrote:
Why should initdb give it [processing
information] to the user if the user didn't request it in the first
place?
Because it shows important information that we want the user to see.
Plus it can be
Jim C. Nasby wrote:
On Thu, Jan 26, 2006 at 11:36:15AM +0100, Peter Eisentraut wrote:
James William Pye wrote:
Why should initdb give it [processing
information] to the user if the user didn't request it in the first
place?
Because it shows important information that we want
Bruce Momjian wrote:
I agree. Let's do the zeroing and see if people complain about it.
I'm complaining. Losing data on a cast is not common behavior.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 9:
I just wasted a couple hours trying to determine why an EXEC_BACKEND
build would randomly fail on Fedora Core 4. It seems the reason is that
by default, recent Linux kernels randomize the stack base address ---
not by a lot, but enough to cause child processes to sometimes be unable
to attach to
Tom Lane wrote:
Define die quite nastily ... you haven't really said what went wrong.
We lost data from this table, and ended up with transactions rolled back
that were in fact committed (ie. data was in DB, program code thought
they were rolled back).
End result was we deemed the database
Folks,
This came up at work...
I have seed database scripts quasi-generated from pg_dump which
include COPY statements, but the data is hard to edit (especially cut
paste operations) when the COPY delimiter is some non-visible
character like \t. So I thought it would be handy to be able to
David Fetter [EMAIL PROTECTED] writes:
I have seed database scripts quasi-generated from pg_dump which
include COPY statements, but the data is hard to edit (especially cut
paste operations) when the COPY delimiter is some non-visible
character like \t.
This seems like an awfully weak
On Thu, Jan 26, 2006 at 10:17:05PM -0500, Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
I have seed database scripts quasi-generated from pg_dump which
include COPY statements, but the data is hard to edit (especially
cut paste operations) when the COPY delimiter is some
28 matches
Mail list logo
