Re: [GENERAL] [pgsql-advocacy] interesting PHP/MySQL thread

2003-06-22 Thread Steve Lane
On 6/22/03 10:57 PM, "Tom Lane" <[EMAIL PROTECTED]> wrote:

> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> Better hurry.  Sterling Hughes is proposing to enable SQlite support by
>> default; that move could be bad for the lobbying of activating Pg
>> support.
> 
> SQlite?   Sure, give it a try.  (I was slightly astonished to compare
> these two pages:
> http://www.hwaci.com/sw/sqlite/omitted.html
> http://www.hwaci.com/sw/sqlite/datatypes.html
> At the very least, one would have to say that the author feels free
> to define those parts of SQL he doesn't like as "not features".  There
> sure isn't anything on the former page to suggest that vast parts of
> the SQL spec are being ignored per the latter page.)
> 
> SQlite is even less competition from our point of view than MySQL is
> ... if the PHP guys think their users will be satisfied with SQlite,
> let them try it for awhile.

No, with all due respect, don't.

These battles aren't won by being a better product. They're won by being
used by more people. And generally speaking, one thing tends to win, whether
it's the best or not.

If you want to exploit this opportunity (which I fervently recommend) than
you should make a big push to have postgres be THE database for PHP. People
latch onto MySQL because it's joined at the hip with PHP. The way to replace
it in that position is, well, by replacing it. MySQL wins, in part, by
piggybacking on the ubiquity of PHP. Let's just replace it with Postgres in
that role, if possible.

> 
> I'd be happy if PHP would adopt a database-neutral stance, ie, nothing
> in particular bundled into their core distribution.  That might not be
> compatible with their project goals though.  Anyone have a feeling about
> how important it is to them to have bundled DB support?  Maybe we could
> talk them into bundling more than one DB interface --- if they put both
> PG and SQlite support into their distro, that'd be fine with me too.

Again, I think a bit of ruthlessness is called for here. You don't want to
coexist. You want to be the default, period.

I mean, assuming that IS what you want :-> It's certainly what I'd like to
see, as a heavy user of both PHP and Postgres.

I'd recommend a semi-formal approach of the Postgres core team to the PHP
core team, asking, in effect, what does the Postgres group need to do to get
pgsql bundled up tight with PHP. If there's discontent there, now's the time
to capitalize on it. Imagine this press release: "PHP team 'unbundles' MySQL
in favor of Postgres". Game over.

I'm trying to get lined up to give a talk on Postgres at the next PHPCon.
>From what I understand, PHPers are eager to hear more about it.

This seems like a huge opportunity that should be seized with both hands
(heck, ALL available hands).

-- sgl


===
Steve Lane

Vice President
The Moyer Group
14 North Peoria St Suite 2H
Chicago, IL 60607

Voice: (312) 433-2421   Email: [EMAIL PROTECTED]
Fax:   (312) 850-3930   Web:   http://www.moyergroup.com
===



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


Re: [GENERAL] SELECT @@IDENTITY

2003-06-23 Thread Steve Lane
On 6/23/03 12:58 PM, "Robert J. Sanford, Jr." <[EMAIL PROTECTED]> wrote:

> Okay, I did a quick search through both the general and SQL lists(1,2)
> trying to determine if there is a PostgreSQL construct equivalent to
> Microsoft SQL Server's "SELECT @@IDENTITY". After performing an insert the
> database caches the last sequence number for each connection and the select
> retrieves that value. Thus if connection A and connection B each inserted
> into the same table they would each know what the value of the sequence was
> immediately after their insert.
> 
> Is there any direct support for this? I know that I can manually code to
> select the nextval of a sequence but the syntactic sugar of SELECT
> @@IDENTITY is really nice.
> 
> Many thanks!

Hi Robert:

You'll want to consult the postgres docs about sequences. The function
you're looking for is called currval(), and selects just what you want --
the most recent value delivered for a sequence over a given connection.
(I've always been curious about how well this behaves, or not, with
connection pooling).

-- sgl


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])