On Thu, Mar 18, 2004 at 10:16:36AM -0500, Tom Lane wrote:
Passing in a relation OID is probably a bad idea anyway, as it ties this
API to the assumption that COPY is only for complete relations. There's
been talk before of allowing a SELECT result to be presented via the
COPY protocol, for
Dear hackers,
please find attached a quick proof of concept for a 'pg_advisor' schema.
Well, the name is 'xpg_advisor' at the time, because it is not a system
schema hence it cannot starts with 'pg_'.
It appears that some support functions would be useful. I've noticed some
are available from
Larry Rosenman wrote:
I thought that once you include libpthread in libpq, that you don't have
to mention it again then you use libpq. Is your platform different
somehow in this regard?
I seem to remember this problem with libcrypt and libpq. Is this the
same problem?
I see that
--- David Garamond [EMAIL PROTECTED] wrote:
--snip --
Also, we're targetting the developers right? Please do not consider
ourselves as being too stupid to differentiate between postgresql.org
-- snip --
IMO this point of view is a short-sighted and narrow one. In
addition to trying
[EMAIL PROTECTED] (Andrew Dunstan) writes:
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:
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 Avenue NW
Washington, DC
On a recent thread Stephan Szabo mentioned some issues with inheritance.
***
On Thu, 19 Feb 2004, Stephan Szabo wrote:
There are two separate things here that are gotchas
The first is that unique constraints don't inherit, and foreign keys must
refer to a unique constraint.
Karel Zak [EMAIL PROTECTED] writes:
It's pity that main idea of current COPY is based on separated lines
and it is not more common interface for streaming data between FE and BE.
Yeah, that was another concern I had. This API would let the formatter
control line-level layout but it would
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
On Fri, Mar 19, 2004 at 09:39:58AM -0500, Tom Lane wrote:
Karel Zak [EMAIL PROTECTED] writes:
It's pity that main idea of current COPY is based on separated lines
and it is not more common interface for streaming data between FE and BE.
Yeah, that was another concern I had. This API
Karel Zak [EMAIL PROTECTED] writes:
The problem with CSV is that it will correctly work with new protocol
only. Because old versions of clients are newline sensitive.
Why? The client-side code doesn't have any real say over the meaning of
the data, at least not in psql-class clients. I
Richard Huxton [EMAIL PROTECTED] writes:
If I pg_restore a DB and don't ANALYSE before a pl/pgsql trigger activates
then that trigger's going to be planned based on the default stats forever
isn't it?
Only for the life of the current backend(s).
If that's still too long for you, you could
Fernando Nasser wrote:
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
please find attached a quick proof of concept for a 'pg_advisor' schema.
Here is a larger but nevertheless still quick proof of concept, alas
with some buggy PL/pgSQL that I wrote with my little finger.
It implements some foreign key type checks for which I submitted be
patches some time ago.
On Friday 19 March 2004 15:04, Tom Lane wrote:
Richard Huxton [EMAIL PROTECTED] writes:
If I pg_restore a DB and don't ANALYSE before a pl/pgsql trigger
activates then that trigger's going to be planned based on the default
stats forever isn't it?
Only for the life of the current
Andrew Dunstan [EMAIL PROTECTED] writes:
There are some wrinkles, though, concerning the interaction of CSV's
notion of escaping and COPY's notion of escaping. If someone want to
undertake this I can flesh those out in a further email.
Please do that, so that the info is in the archives in
I wrote:
Fernando Nasser wrote:
[snip re multiline CSV fields]
I have never seen such a beast,
Export from a spreadsheet where people have formated the cell with
the address on it.
Well, I just tried with OpenOffice on my RH9 box, and it translated
the line breaks in the cell into spaces
Dear hackers,
I'm looking for an array_index function that would return the index of the
occurence of some element in an array. I noticed that I can know whether a
element is in the array with ANY, but I also need the actual index.
There is no such function under that name, and I cannot find
Karel Zak [EMAIL PROTECTED] writes:
And what \n in attibutes data in CSV? I think CSV format doesn't use
some escape for newline char. It means psql with \copy cannot be sure
with CSV.
I think CSV only allows embedded newlines that are either escaped, or
inside quotes. COPY doesn't
If I pg_restore a DB and don't ANALYSE before a pl/pgsql trigger activates
then that trigger's going to be planned based on the default stats forever
isn't it?
--
Richard Huxton
Archonet Ltd
---(end of broadcast)---
TIP 8: explain analyze is
Environment:
SunOS 5.8 Generic_108528-27 sun4u sparc SUNW,Ultra-250
gcc version 3.3.1
PostgreSQL-7.4.2
./configure --with-java --enable-thread-safety
make results in:
gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes
-Wmissing-declarations -fPIC -I.
[ moving thread to hackers ]
Fabien COELHO [EMAIL PROTECTED] writes:
However, I still stick with my bad simple idea because the simpler the
better, and also because of the following example:
...
psql SELECT count_tup('pg_shadow');
ERROR: syntax error at or near FRM at character 22
CONTEXT:
quote who=Andrew Dunstan
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
Bruce Momjian wrote:
OK, so for the separator, quote, and escape options:
separator is ,
quote is
escape is
so if the quote and escape are the same, then a double denotes a
single?
Yes. i.e. with the above settings abcdef - abcdef
cheers
andrew
Josh Berkus wrote:
Overall, I assert again that approaching this issue through COPY enhancements
is really not the way to go.We should be looking at a client utility,
like pg_import and pg_export. The primary purpose of COPY is bulk loads
for backup/restore, and I'm against doing a lot
Andrew Dunstan wrote:
Josh Berkus wrote:
Overall, I assert again that approaching this issue through COPY enhancements
is really not the way to go.We should be looking at a client utility,
like pg_import and pg_export. The primary purpose of COPY is bulk loads
for
Fabien COELHO wrote:
Am I unlucky or just blind?
Unlucky I guess. No such function, least not yet.
Joe
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL
I wrote:
Note, too, that the preferred method isn't likely to depend just on the
operating system, it's likely to depend also on the filesystem type
being used.
Linux provides quite a few of them: ext2, ext3, jfs, xfs, and reiserfs,
and that's just off the top of my head. I imagine the
28 matches
Mail list logo
