473,889 Members | 1,361 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Is my MySQL Gaining ?

Dear all,

Their was a huge rore about MySQL recently for something in java functions
now theirs one more

http://www.mysql.com/doc/en/News-5.0.x.html

Does this concern anyone.

What I think is PostgreSQL would have less USP's (Uniqe Selling Points
though we dont sell) now.

What do you think yes we PostgreSQL users need some introspection.

Regards,
Vishal Kashyap.

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Nov 12 '05
175 11574
Casey Allen Shobe wrote:
I think that a combined package of PostgreSQL and pgAdmin III should be
available.


Just convince your distribution's postgresql package maintainer to add
pgadmin iii to the "suggests/recommends" portion of the package
management metadata.

Alex
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 12 '05 #71
On Sun, Dec 28, 2003 at 12:57:10 -0500,
Casey Allen Shobe <cs****@softhom e.net> wrote:

Ahh, I have seen those...but they're specific to psql, and if memory serves me
correct I wasn't able to use the variables within queries, either. I need
something I can use over ODBC (within a single transaction, of course).
These can sometimes solve problems that you can't seem to solve any other
way, and other times can improve query response time *greatly* (say, by
running a subquery once and assigning the result to a variable used 40 times
in the final statement instead of running 40 subqueries).


You should be handle to this case by using the subselect query in the from
clause and then doing a join to make the value available where needed.

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddres sHere" to ma*******@postg resql.org)

Nov 12 '05 #72
Shridhar Daithankar <sh************ *****@myrealbox .com> writes:
That is right. but that fact remains that postgresql documentation is just
sufficient. If you read the manual and follow it religously to comma and
fullstop, it tells you everythings. But it certainly isn't a place where you
can glance over it and get hang of it.


This is surely true, and I've not seen anyone denying it. The people
who are doing development are, um, not strong at documentation (I
include myself here). What we need are some folks to step up and
improve the documentation --- and then maintain it in the face of future
changes. Any volunteers out there? This is an open-source project
after all, and that means "scratch your own itch" among other things...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postg resql.org so that your
message can get through to the mailing list cleanly

Nov 12 '05 #73
Chris Travers wrote:
The example I gave was one where my app was designed to replace the old way
of doing things (in this case excel). Replacing an Excel spreadsheet with a
database-driven appliation is one area where you have no additional risk of
information loss when you are running any RDBMS on the system.

Also, here in Indonesia, most of these B&B's charge less than $30/night.
Purchasing a new system (often $700 or more) is the equivalent of 23
room-nights (for a place which typically has fewer than 10 rooms). Used
PC's are out of the question because usually they have hardware issues, and
so the cost savings would be marginal.

Please remember that the economic tradeoff of whether to buy an additional
system varies quite a bit around the world. For this reason, I decided to
build my application to be platform and database agnostic, supporting both
Firebird and PostgreSQL.


So one more reason to buy cheap hardware and avoid to pay M$ licenses or
not ?
Regards
Gaetano Mendola
Nov 12 '05 #74
I agree with you (speaking as a newbie) I don't believe any dumbing down
is necessary at all. I DO believe however that a decent introduction to
the more important concepts (Triggers, Fkeys, Stored Proc, Views) that
people from lesser systems (MySQL, Access) may not be familiar with.
What they do, how they help, and why they are generally a good thing.
This intro would probably fit either in the tutorial or in the User Guide.

Don't hold peoples hand for them, but at least provide them with the
tools they need to make an educated decision.

T.

Shridhar Daithankar wrote:
On Monday 29 December 2003 12:47, Tom Lane wrote:

Shridhar Daithankar <sh************ *****@myrealbox .com> writes:

That is right. but that fact remains that postgresql documentation is
just sufficient. If you read the manual and follow it religously to comma
and fullstop, it tells you everythings. But it certainly isn't a place
where you can glance over it and get hang of it.

This is surely true, and I've not seen anyone denying it. The people


Well, for newbies to postgresql, let's state this fact upfront and not make
them discover it..:-)
who are doing development are, um, not strong at documentation (I
include myself here). What we need are some folks to step up and
improve the documentation --- and then maintain it in the face of future
changes. Any volunteers out there? This is an open-source project
after all, and that means "scratch your own itch" among other things...


If you ask me, let's not do that. Not at least on a grand scale. Isolated
areas are OK on case by case basis..

I regualrly use development build documentation from developers.post gresql.org
and I have seen the documentation in source code. In my view, postgresql
developers do document it very clearly whenever required.

If we dilute the documentation too much, that will make things simpler
initially but that will simply create a maintainance nightmare as one has to
maintain much larger amount of documentation.

And once you get used to precise style of postgresql documentation, going back
to anything else is a pain. ( MSDN.. I scream at nights.... but I digress).

IMO documentation of postgresql is fine overall. What we need to do is.

1. State upfront that this is not handholding.

It will make lots of things easier and offload work of expanding documents
given limited human resources working on the project. A disclaimer is far
easier to maintain than a manual..:-)

And it will prepare anybody for upcoming hardships..:-)

2. Document and reuse it.

Personally I would like to see responses on general and oter such list as
URLs. If we answer it repeatedly, let's document it and point the people to
them. Let them dig around 3-4 URLs around it and they will have islands of
enlightenments . Over the period, these island will merge in a great
landscape..:-)

Just a thought..

Shridhar

P.S. If somebody thinks I can not imagine how a newbie feels, I will agree.
But looking back, dumbing down anything is not good in long term..an
experience that is
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postg resql.org


Nov 12 '05 #75
By that logic then, we can probably ditch the PG Tutorial altogether and
provide a quick ref card of PG commands and keywords, with a few pages
on how PG is different should be plenty.

The bisggest problem that I faced when moving to PG was the complete
lack of any cetralised information source for this information. Sure
there are tutorials on the web, first track them down, then convert
their use to PG then collate them, then make some sense of it all.
This is the kind of aloofness that I have mentioned previously, just
because it doesn't belong, doesn't mean it's not needed, and it only
needs to be written once. Although I know some of the concepts and I'm
beginning to grock them, I'm still trying to collate enough to satisfy
my needs.

Assuming yo *do* want to grow the PG community and attract people from
other systems, the easier the transition for them, the less likely they
are to look elsewhere for something that appears easier. Easier
doesn't always mean easier to use, sometimes it can mean easier to get
to grips with.

T.

Shridhar Daithankar wrote:
For one thing, these thing do not belong to postgresql documentation.

But I don't believe there is shortage of material on these topics on web and
in print.

However if you are refering to explaining these things, w.r.t. postgresql, I
would be more than happy to churn out some extremely basic tutorials.

Can you tell us what all you need? Rephrasing, if you know these(and some
other) concpets by now, what all you missed while learning postgresql?

It may sound like stupid question but unlearning things out of imagination is
not easy...:-)

Shridhar


---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 12 '05 #76
I agree with most of this sentiment. Even knowing SQL and RDBMs reasonably
well, there is still a significant effort involved in moving from another
RDBMS (in my case Oracle) to postgres.

The postgres docs provide much all the detail (in a very concise form).
The hard part is putting all the different pieces together to solve some
problem. In fact, this is where the postgres users list is so good,
because the support and feedback from it is excellent.

Contrast this page from the docs (for the update statement),
http://www.postgres.org/docs/current...ql-update.html with
Oracle's (for 8.1.7)
http://download-west.oracle.com/docs...7a.htm#2067717

Some might feel that much of the information is redundant or bloat. I
disagree - you get a feel for what is possible as well as links to other
commands, subtopics, and concept explanations.

Someone commented that maintaining docs (of this sort) would be too hard -
I disagree. Many of the commands are *mostly* implementation agnostic, and
the initial docs would require siginificant effort to build, but should
only require moderate maintenance as features are added or modified.

Just my two cents (again).

John Sidney-Woollett

ps And yes, I would be willing to help once my current project is complete...

Tony said:
By that logic then, we can probably ditch the PG Tutorial altogether and
provide a quick ref card of PG commands and keywords, with a few pages
on how PG is different should be plenty.

The bisggest problem that I faced when moving to PG was the complete
lack of any cetralised information source for this information. Sure
there are tutorials on the web, first track them down, then convert
their use to PG then collate them, then make some sense of it all.
This is the kind of aloofness that I have mentioned previously, just
because it doesn't belong, doesn't mean it's not needed, and it only
needs to be written once. Although I know some of the concepts and I'm
beginning to grock them, I'm still trying to collate enough to satisfy
my needs.

Assuming yo *do* want to grow the PG community and attract people from
other systems, the easier the transition for them, the less likely they
are to look elsewhere for something that appears easier. Easier
doesn't always mean easier to use, sometimes it can mean easier to get
to grips with.

T.

Shridhar Daithankar wrote:
For one thing, these thing do not belong to postgresql documentation.

But I don't believe there is shortage of material on these topics on web
and
in print.

However if you are refering to explaining these things, w.r.t.
postgresql, I
would be more than happy to churn out some extremely basic tutorials.

Can you tell us what all you need? Rephrasing, if you know these(and some
other) concpets by now, what all you missed while learning postgresql?

It may sound like stupid question but unlearning things out of
imagination is
not easy...:-)

Shridhar


---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postg resql.org so that your
message can get through to the mailing list cleanly

Nov 12 '05 #77
Apologies, try this link instead:

http://miami.int.gu.edu.au/dbs/7016/...7a.htm#2067717

The previous one required you to be signed with technet - the one above
should be viewable by all.

John

John Sidney-Woollett said:
I agree with most of this sentiment. Even knowing SQL and RDBMs reasonably
well, there is still a significant effort involved in moving from another
RDBMS (in my case Oracle) to postgres.

The postgres docs provide much all the detail (in a very concise form).
The hard part is putting all the different pieces together to solve some
problem. In fact, this is where the postgres users list is so good,
because the support and feedback from it is excellent.

Contrast this page from the docs (for the update statement),
http://www.postgres.org/docs/current...ql-update.html with
Oracle's (for 8.1.7)
http://download-west.oracle.com/docs...7a.htm#2067717

Some might feel that much of the information is redundant or bloat. I
disagree - you get a feel for what is possible as well as links to other
commands, subtopics, and concept explanations.

Someone commented that maintaining docs (of this sort) would be too hard -
I disagree. Many of the commands are *mostly* implementation agnostic, and
the initial docs would require siginificant effort to build, but should
only require moderate maintenance as features are added or modified.

Just my two cents (again).

John Sidney-Woollett

ps And yes, I would be willing to help once my current project is
complete...

Tony said:
By that logic then, we can probably ditch the PG Tutorial altogether and
provide a quick ref card of PG commands and keywords, with a few pages
on how PG is different should be plenty.

The bisggest problem that I faced when moving to PG was the complete
lack of any cetralised information source for this information. Sure
there are tutorials on the web, first track them down, then convert
their use to PG then collate them, then make some sense of it all.
This is the kind of aloofness that I have mentioned previously, just
because it doesn't belong, doesn't mean it's not needed, and it only
needs to be written once. Although I know some of the concepts and I'm
beginning to grock them, I'm still trying to collate enough to satisfy
my needs.

Assuming yo *do* want to grow the PG community and attract people from
other systems, the easier the transition for them, the less likely they
are to look elsewhere for something that appears easier. Easier
doesn't always mean easier to use, sometimes it can mean easier to get
to grips with.

T.

Shridhar Daithankar wrote:
For one thing, these thing do not belong to postgresql documentation.

But I don't believe there is shortage of material on these topics on web
and
in print.

However if you are refering to explaining these things, w.r.t.
postgresql, I
would be more than happy to churn out some extremely basic tutorials.

Can you tell us what all you need? Rephrasing, if you know these(and
some
other) concpets by now, what all you missed while learning postgresql?

It may sound like stupid question but unlearning things out of
imagination is
not easy...:-)

Shridhar


---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postg resql.org so that your
message can get through to the mailing list cleanly

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Nov 12 '05 #78
Alex Satrapa (Sunday 28 December 2003 22:16)
Just convince your distribution's
My what? I don't use no stinkin' distribution :).
postgresql package maintainer
That would be postgresql.org, I know not of binary packages.
"suggests/recommends" portion of the package management metadata.


Tar does not provide such metadata, and a suggestion is hardly the same as an
inclusion.

I'm just saying that it would be nice to include both CLI and GUI interfaces,
not to mention things like ODBC, as an alternative to the "minimalist "
download.

I got a private reply suggesting putting together a "distributi on" of
PostgreSQL including extras, so that may be a possible route as well.

Vertu sŠll,

--
Sig■ˇr Bj÷rn Jar­arson (Casey Allen Shobe)
http://rivyn.livejournal.com

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Nov 12 '05 #79
> I'm in a similar situation. My app is currently PG-only (although I
_might_ be able to get it work with Firebird eventually). Currently I have
to sell Linux to prospective clients in addition to my app. A native
Windows version would make my life a bit easier.

Same here.

Our "clients" use legacy medical office software that 99% runs
on Windows. We offer add-ons (tailored mini-versions of our
main application :-) and thus get OSS (Python, PostgreSQL,
wxWindows, sometimes Linux itself) into their offices and onto
their networks. Most of the time the main difficulty is to figure
out how to offer PostgreSQL in their environment (yes, we know
about CygWin).

("clients" because we don't do business as in selling stuff)

Karsten Hilbert, MD

www.gnumed.org
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddres sHere" to ma*******@postg resql.org)

Nov 12 '05 #80

This thread has been closed and replies have been disabled. Please start a new discussion.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.