Bruce Momjian <[EMAIL PROTECTED]> writes:
> Should we set the datestyle at the top of pg_dump files like we do with
> encoding and other settings? Seems we should.
That was dealt with quite a while back.
regards, tom lane
---(end of broadcast)---
Never mind. I found out that pg_dump already does a SET datestyle =
'ISO' before dumping, so all the dates are in ISO format.
I just need to mention that COPY honors Datesyle.
---
pgman wrote:
> I just found out that dates
I just found out that datestyle affects the output of COPY, and hence
pg_dump:
test=> create table test(x date);
CREATE
test=> insert into test values ('2001-07-31');
INSERT 17239 1
test=> set datestyle to 'postgres, dmy';
SET
test=> copy t
On Thursday 01 April 2004 12:52, Tony Reina wrote:
> Last link was wrong.
>
> Here's the correct one.
> http://www.dertech.com/pgmex/pgmex.html
>
Updated website code in CVS, should appear after the next update/build cycle.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} Postg
... on projects.postgresql.org, or similar.They really aren't doing any
good in /contrib.
I've already set up a category "conversion tools" on pgFoundry, and my idea
was one project per target system.
I reckon that by far the best way to do a mysql2pgsql converter is to
just modify mysqldum
On Wed, 14 Apr 2004, Bruce Momjian wrote:
> > I'd be happy to take the lead as maintainer of my2pg. But, I want to move it
> > to pgFoundry (due for launch as soon as I get my other 10 super-urgent tasks
> > out of the way) , and take it out of /contrib. I feel pretty strongly
> > that it wil
Josh Berkus <[EMAIL PROTECTED]> writes:
>> And what to do with the other db conversion tools? Seems they should be
>> kept together.
> ... on projects.postgresql.org, or similar.They really aren't doing any
> good in /contrib.
Fair enough. They're not tightly tied to the backend, so I see
Bruce,
> And what to do with the other db conversion tools? Seems they should be
> kept together.
... on projects.postgresql.org, or similar.They really aren't doing any
good in /contrib.
I've already set up a category "conversion tools" on pgFoundry, and my idea
was one project per targe
Marc G. Fournier wrote:
> On Wed, 14 Apr 2004, Bruce Momjian wrote:
>
> > > I'd be happy to take the lead as maintainer of my2pg. But, I want to move it
> > > to pgFoundry (due for launch as soon as I get my other 10 super-urgent tasks
> > > out of the way) , and take it out of /contrib. I fe
On Wed, 2004-04-14 at 15:17, elein wrote:
> Is anyone working on an analysis of where PostgreSQL
> meets, deviates and exceeds the new SQL2003 standard?
>
> If not, I'm going to work on one, but I don't want
> to re-invent the wheel. If someone else has done some
> of this or wants to do some of t
>elein
>
> Is anyone working on an analysis of where PostgreSQL
> meets, deviates and exceeds the new SQL2003 standard?
>
> If not, I'm going to work on one, but I don't want
> to re-invent the wheel. If someone else has done some
> of this or wants to do some of this it would be
> better to work t
Joe Conway wrote
> Tom Lane wrote:
> > Personally I rely quite a lot on setting PGDATA to keep
> straight which
> > installation I'm currently working with, so I'm not going
> to be happy
> > with a redesign that eliminates that variable without providing an
> > adequate substitute :-(
>
> I'll se
Is anyone working on an analysis of where PostgreSQL
meets, deviates and exceeds the new SQL2003 standard?
If not, I'm going to work on one, but I don't want
to re-invent the wheel. If someone else has done some
of this or wants to do some of this it would be
better to work together.
The goal is
Josh Berkus wrote:
> Tom,
>
> > Hmm ... seems like the big question is not "where to keep them" but
> > "who's gonna maintain them" ... without active maintenance they're
> > just dead bits wherever they're stored, because MySQL and Postgres
> > are both moving targets.
> >
> > These tools are a n
Mark Kirkwood wrote:
Tom Lane wrote:
I think if you spelled the subdir name "config" rather than "etc",
it would be more obvious what's what.
How about 'conf' - (familiar to anyone who has used apache or tomcat )
How about 'etc' - (familiar ot anyone who has used unix)
--
Andrew Hammond
-
Greetings,
As mentioned in the PostgreSQL Weekly News, SQL2003 has been approved.
Looking at one of the recent drafts it appears that MERGE has been
added to the spec. MERGE is described as "Conditionally update rows
of a table, or insert new rows into a table, or both." Support for
th
Tom,
> Hmm ... seems like the big question is not "where to keep them" but
> "who's gonna maintain them" ... without active maintenance they're
> just dead bits wherever they're stored, because MySQL and Postgres
> are both moving targets.
>
> These tools are a not insignificant part of our Plan f
Tom Lane wrote:
Personally I rely quite a lot on setting PGDATA to keep straight which
installation I'm currently working with, so I'm not going to be happy
with a redesign that eliminates that variable without providing an
adequate substitute :-(
I'll second that.
Joe
---
> > The compilers from Microsoft and Borland atleast aren't
> > compatible.
>
> But that shows up as link errors, not at runtime, right?
Correct. Microsoft and Borland use different library packaging formats,
COFF and OMF. However (non C++) DLLs are compatible and you can extract
a static lib f
On Wed, Apr 14, 2004 at 12:22:18AM +0200, Kurt Roeckx wrote:
> > But in the case of x86 (among others) that's the in-register
> > representation, no? IIRC they are stored to memory as 64-bit doubles at
> > best.
>
> You also have "long double"s on some compilers which could be 80 bit.
Actually
>
>
> How can I use a prepared select statement as mentioned in the documentation=
> on SQL PREPARE. Preparing the statement is easy, the problem is using the =
> plan to get a cursor. My assumption is the SQL OPEN command is not document=
> ed or there is some other libpq API to make this happe
On Wed, 14 Apr 2004, Fabien COELHO wrote:
> printf("SELECT * FROM foo WHERE field1 = '%s'",
>latin1_to_database_encoding(...));
And how do you do this if the database encoding is latin2? You can not
convert latin1 to latin2.
The specification was written like this to handle things like
> > I cannot see where I could use such a feature.
>
> Applications usually generate queries.
Sure.
> So you can do things like
>
> printf ("SELECT * FROM foo WHERE field1 = _latin1'%s';", my_latin1_data);
Hmmm... I guess the following was too complicated. You need a library
for conversion. You
On Wed, 14 Apr 2004, Fabien COELHO wrote:
> > ... WHERE field1 = _latin1'FooBar' and field2 = _utf8'Åäö'
> >
> > different charsets or this is not going to work very well.
>
> What "editor" or terminal is supposed to be able to generate text in
> different encodings depending on the part of the
> My next question is about lexing. The spec says that one can use strings
> of different charsets in the queries, like:
>
> ... WHERE field1 = _latin1'FooBar' and field2 = _utf8'Åäö'
>
> different charsets or this is not going to work very well.
Sorry for this maybe stupid question about an mu
25 matches
Mail list logo
