On Sun, Jun 11, 2006 at 15:13:39 +0900,
Michael Glaesemann <[EMAIL PROTECTED]> wrote:
>
> That's different from being able to show equivalence between two
> ranges in different representations, e.g., r1 = r2 iff a1 = a2 and b1
> = next(b2). As Bruno pointed out earlier, in some cases, a clos
Already on TODO:
pg_dump:
o %Add CSV output format
---
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > Something someone said on IRC just now triggered a little memory ... I
> > think we shoul
Martijn van Oosterhout writes:
> But the effect would change still, even with readline enabled. If
> readline is compiled in and you press control-C, our handler is still
> called. Currently, we siglongjmp out of readline() and start again. If
> you only set a flag like proposed, we won't break ou
[ moving to -hackers to get some more eyeballs on the question ]
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Sun, 2006-06-11 at 17:53 -0400, Alvaro Herrera wrote:
>> Here I repost the patch to implement non-transactional catalogs, the
>> first of which is pg_ntclass, intended to hold the non-tran
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
> Tom Lane írta:
>> You're missing the hard part: NEXT VALUE FOR is sufficiently different
>> from nextval() that it will be very painful to implement.
> Do you mean the allowed and denied contexts of the
> NEXT VALUE FOR expression in section 6.13?
Can't -- the main production database is over at a CoLo site with access
only available via SSH, and tightly-restricted SSH at that. Generally
one of the developers will SSH over to the server, pull out whatever
data is needed into a text file via psql or pg_dump, scp the file(s)
back here and send
Bill Bartlett wrote:
Here's me speaking up -- I'd definitely use it! As a quick way to pull
data into Excel to do basic reports or analysis, a CSV format would be
great.
Why not just use ODBC?
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/S
Tom Lane írta:
=?iso-8859-2?Q?B=F6sz=F6rm=E9nyi_Zolt=E1n?= <[EMAIL PROTECTED]> writes:
Well, I read all sections of 5WD-02-Foundation-2003-09.pdf
where "identity" appears, here are the list of changes that will
be needed for an identity column:
You're missing the hard part: NEXT VALUE
Here's me speaking up -- I'd definitely use it! As a quick way to pull
data into Excel to do basic reports or analysis, a CSV format would be
great. Some of our users currently pull data into Excel for quickie
analysis, but creating fixed-width data via psql requires them to parse
the data and d
On Mon, Jun 12, 2006 at 02:15:59PM -0400, Andrew Dunstan wrote:
> Naturally you won't have a use for it, but I suspect others might (in
> which case they had better speak up ;-) )
I'd bet that those who would find this useful are far more likely to be
on -general and not in here.
--
Jim C. Nasby
Joshua D. Drake wrote:
> What is easier?
>
> test=# select column_name, data_type from columns where table_schema !=
> 'pg_catalog' and table_name = 'email';
\d email
So, would you change psql's \d logic to use the new function? While
answering that, consider that you'd lose the ability to qu
Hi,
Jim C. Nasby írta:
On Mon, Jun 12, 2006 at 02:27:31PM +0200, B?sz?rm?nyi Zolt?n wrote:
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
after some experimentation, I came up with the attached patch,
which implements parsing the following SERIAL types:
As has been pointed
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> One thing that I think should be clarified... why wouldn't pg_dump be
> able to use these functions? Is it because of version compatability?
This has already been gone over more than once in this thread, let
alone the prior one, but here are some reason
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Something someone said on IRC just now triggered a little memory ... I
think we should provide an option to have pg_dump work in CSV mode
rather than text mode. This probably doesn't have much importance in the
case of text dumps,
No it won't, not if there are tabs in the data.
Hmmm then would just double quoting the data work? At least in OOCalc
(and IIRC Excel) there is the ability to select a text delimiter.
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Suppor
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Something someone said on IRC just now triggered a little memory ... I
> think we should provide an option to have pg_dump work in CSV mode
> rather than text mode. This probably doesn't have much importance in the
> case of text dumps, but in custom
Josh,
> > This should be a pretty low cost item, I expect (good newbie project?)
>
> Uhh... just about any application that can import CSV can import our
> dumps. It just tell it the delimiter is a tab.
Actually, there was an Summer of Code applcation to do this, but with all
the other nifty stu
Joshua D. Drake wrote:
Andrew Dunstan wrote:
Something someone said on IRC just now triggered a little memory ...
I think we should provide an option to have pg_dump work in CSV mode
rather than text mode. This probably doesn't have much importance in
the case of text dumps, but in custom o
=?iso-8859-2?Q?B=F6sz=F6rm=E9nyi_Zolt=E1n?= <[EMAIL PROTECTED]> writes:
> Well, I read all sections of 5WD-02-Foundation-2003-09.pdf
> where "identity" appears, here are the list of changes that will
> be needed for an identity column:
You're missing the hard part: NEXT VALUE FOR is sufficiently d
Andrew Dunstan wrote:
Something someone said on IRC just now triggered a little memory ... I
think we should provide an option to have pg_dump work in CSV mode
rather than text mode. This probably doesn't have much importance in the
case of text dumps, but in custom or tar dumps where you mi
"Dave Page" writes:
>> Following a pgAdmin bug report, I noticed that pg_get_viewdef doesn't
>> return the opclass when called for a specific column (in 8.1
>> at least) -
> Bah, I mean pg_get_indexdef of course :-)
This is intentional --- whoever asked for the per-column variant of
the indexd
Something someone said on IRC just now triggered a little memory ... I
think we should provide an option to have pg_dump work in CSV mode
rather than text mode. This probably doesn't have much importance in the
case of text dumps, but in custom or tar dumps where you might want to
get at ind
Before we pull pg_dump to bits let's identify some actual benefit from
doing so. If you look at the code you will see that it is more than
somewhat complex. A large scale move like you are proposing would be
very high risk, IMNSHO.
From a person who deals with customer migrations daily persp
> -Original Message-
> From: Thomas Hallgren [mailto:[EMAIL PROTECTED]
> Sent: 11 June 2006 10:07
> To: Mark Cave-Ayland
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: Proposal for debugging of server-side stored procedures
Hi Tom,
(cut)
> Obviously I'm not a Perl nor Python hacker.
Jim C. Nasby wrote:
The only reason I've been able to think of for why pg_dump wouldn't use
a *back end* function for this is because it would then be limited to
dumping in the format provided by that backend, which could become an
issue when upgrading. If that is in fact a problem, it might be
On Mon, Jun 12, 2006 at 02:27:31PM +0200, B?sz?rm?nyi Zolt?n wrote:
> > Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
> >> after some experimentation, I came up with the attached patch,
> >> which implements parsing the following SERIAL types:
> >
> > As has been pointed out before, it would be a
On Mon, Jun 12, 2006 at 12:24:36AM -0400, Kris Kennaway wrote:
> On Sun, Jun 11, 2006 at 10:07:13PM -0500, Jim C. Nasby wrote:
> > On Sun, Jun 11, 2006 at 09:58:33PM -0400, Tom Lane wrote:
> > > Kris Kennaway <[EMAIL PROTECTED]> writes:
> > > > On Sun, Jun 11, 2006 at 07:43:03PM -0400, Tom Lane wro
Tom Lane wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > Trying to get back on point. What is the scope of work for the TODO
> > item? Forget everything else I brought up. What is the goal of the
> > existing TODO?
>
> I'm not sure that the TODO item has a reason to live at all, but s
On Mon, Jun 12, 2006 at 08:49:00AM -0400, Andrew Dunstan wrote:
> Yes ... except that I don't see any good reason to have these in a
> contrib module and keep, say, pg_get_viewdef() in core. They belong
> together, I think, and I don't think they represent so much bloat that
> having them in cor
> >> This bothers me a bit, because in
> >> fact the effects if any of the tested query would have been rolled
> >> back. Not sure we have any choice though. If we expose the error
> >> then we'll have problems with clients not showing the EXPLAIN
> >> results.
>
> > I think we should leave
Hi Tom,
I had a look, and don't really know what to do!
I played with pltcl.c line 1318, adding a like like
elog(LEVEL,UTF_U2E(argv[2]));
where LEVEL is WARNING,INFO,ERROR,DEBUG2,LOG,NOTICE
so far, WARNING,INFO,NOTICE work fine, not the others...
I just don't understand, and don't really know w
Mark Kirkwood wrote:
Jim C. Nasby wrote:
Here's the relevant thread:
http://archives.postgresql.org/pgsql-hackers/2005-12/msg00756.php
The intention is to flesh out the existing pg_get_blahdef functions,
such as pg_get_viewdef(). This clearly means that the functions should
output a comple
On Sun, Jun 11, 2006 at 10:07:13PM -0500, Jim C. Nasby wrote:
> On Sun, Jun 11, 2006 at 09:58:33PM -0400, Tom Lane wrote:
> > Kris Kennaway <[EMAIL PROTECTED]> writes:
> > > On Sun, Jun 11, 2006 at 07:43:03PM -0400, Tom Lane wrote:
> > >> Let's see the evidence.
> >
> > > The calls to setproctitle
> Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
>> after some experimentation, I came up with the attached patch,
>> which implements parsing the following SERIAL types:
>
> As has been pointed out before, it would be a seriously bad idea to
> implement the SQL syntax for identity columns without
Bah, I mean pg_get_indexdef of course :-)
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Dave Page
> Sent: 12 June 2006 12:12
> To: pgsql-hackers@postgresql.org
> Subject: [HACKERS] pg_get_viewdef - opclass
>
> Following a pgAdmin bug report, I n
Following a pgAdmin bug report, I noticed that pg_get_viewdef doesn't
return the opclass when called for a specific column (in 8.1 at least) -
for example, for the index:
CREATE UNIQUE INDEX bar_pattern_idx2 ON foofoo USING btree
(lower((bar)::text) bpchar_pattern_ops, bar2)
A query on column 1 r
36 matches
Mail list logo
