Look at this:
http://www.zend.com/images/survey/14.gif

I belive that there is only one reason why most of people are using
MySQL - it has native, very easy to install version for windows.




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

"Marek Lewczuk" <newsy@lewczuk.com> writes:[color=blue]
> Look at this:
> http://www.zend.com/images/survey/14.gif
> I belive that there is only one reason why most of people are using
> MySQL - it has native, very easy to install version for windows.[/color]

No, that survey is specific to people using PHP, and the reason for the
skew is that PHP (used to) ship with built-in support for MySQL --- and
no other database. I don't think you can draw any conclusions about
which OS they are running on.

Now that MySQL AB has put a stake through the heart of that connection
by GPL'ing their client libraries, we might start to get a little better
traction with PHP users...

regards, tom lane

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

On Friday 19 September 2003 16:18, Tom Lane wrote:[color=blue]
>
> Now that MySQL AB has put a stake through the heart of that connection
> by GPL'ing their client libraries, we might start to get a little better
> traction with PHP users...[/color]

Speaking as a PG+PHP user, the new plphp procedural language should be very
useful. I fully intend to be writing a code generator that can produce
validation functions to be run in PG and in the app. About time I stopped
writing two sets of validation code. I'll stick it on gborg if no-one gets
there before me.

One thing I think would be useful is another pseudo-var in PG, something like
APP_SESSION_VAR which can be set and then used in PG queries. This would make
it much easier to write queries like:

CREATE VIEW my_project_list AS
SELECT * FROM project_list WHERE owner=APP_SESSION_VAR

At the moment you can do this sort of thing easily enough for straightforward
queries, but views/function bodies are a PITA.

Tom - if I offered to produce a patch for something like this - either a var
or a function pair (get_app_session_var(), set_app_session_var(varchar))
would it be likely to be accepted? I've probably got some free time towards
the end of the year.

--
Richard Huxton
Archonet Ltd

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

Richard Huxton <dev@archonet.com> writes:[color=blue]
> One thing I think would be useful is another pseudo-var in PG,
> something like APP_SESSION_VAR which can be set and then used in PG
> queries.[/color]
[color=blue]
> Tom - if I offered to produce a patch for something like this - either a var
> or a function pair (get_app_session_var(), set_app_session_var(varchar))
> would it be likely to be accepted?[/color]

It'd depend a lot on the details of what you propose, I think. True
variables seem like they'd be rather invasive, not to mention possibly
error-prone (is "foo" a variable or a column reference?). However you
could do something pretty self-contained in the form of a couple of
functions. I'd suggest they support more than just one variable, btw.
How about "set_session_variable(varname, varvalue)" and
"get_session_variable(varname)"?

I should think we'd at least accept that as a contrib module; whether it
would become mainstream would probably depend on the level of interest.

regards, tom lane

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

Tom Lane wrote:
[color=blue]
> Richard Huxton <dev@archonet.com> writes:
>[color=green]
>>One thing I think would be useful is another pseudo-var in PG,
>>something like APP_SESSION_VAR which can be set and then used in PG
>>queries.[/color]
>
>[color=green]
>>Tom - if I offered to produce a patch for something like this - either a var
>>or a function pair (get_app_session_var(), set_app_session_var(varchar))
>>would it be likely to be accepted?[/color]
>
>
> It'd depend a lot on the details of what you propose, I think. True
> variables seem like they'd be rather invasive, not to mention possibly
> error-prone (is "foo" a variable or a column reference?). However you
> could do something pretty self-contained in the form of a couple of
> functions. I'd suggest they support more than just one variable, btw.
> How about "set_session_variable(varname, varvalue)" and
> "get_session_variable(varname)"?
>
> I should think we'd at least accept that as a contrib module; whether it
> would become mainstream would probably depend on the level of interest.[/color]

In the past, one hack would be to use setenv() and getenv() of the
backend to implement these functions. What about a contrib module that:

1) At set_session_variable(), a getenv() on the key
(PG_APP_SESSION_VAR) is made to see if memory has already been
allocated for a private variable map. If so, add the variable to the
map, else allocate a new map and set it's address using setenv().

2) At get_session_variable() a getenv() on the key
(PG_APP_SESSION_VAR) is made to see if a map exists. If so, it looks
into the map for the value of the name specified and returns it.

3) At get reset_session_variables() a getenv() on the key
(PG_APP_SESSION_VAR) is made to see if a map exists. If so, it is emptied.

This way, no change to any internal postgres code is required, the
memory allocated to the session-specific variables gets released at
backend closing, etc.

Would something like that be acceptable?

Mike Mascari
mascarm@mascari.com







---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

Mike Mascari <mascarm@mascari.com> writes:[color=blue]
> In the past, one hack would be to use setenv() and getenv() of the
> backend to implement these functions. What about a contrib module that:[/color]

Uh, what exactly does it buy you to involve an environment variable
in this process? I think it just adds fragility. (For example,
exposing setenv to the user creates the risk that he'll overwrite
something of importance, like PATH.)

regards, tom lane

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

Tom Lane wrote:
[color=blue]
> Mike Mascari <mascarm@mascari.com> writes:
>[color=green]
>>In the past, one hack would be to use setenv() and getenv() of the
>>backend to implement these functions. What about a contrib module that:[/color]
>
>
> Uh, what exactly does it buy you to involve an environment variable
> in this process? I think it just adds fragility. (For example,
> exposing setenv to the user creates the risk that he'll overwrite
> something of importance, like PATH.)[/color]

Actually, I meant that setenv() and getenv() would only be used to
store the memory address of a privately manipulated variable map. I
did not mean that it should actually be used to store and retrieve the
variables themselves. If there is already a way to palloc() memory
using a key that lives for the lifetime of a backend, then that's
obviously the way to go. I was proceeding under the assumption that
there wasn't.

Mike Mascari
mascarm@mascari.com



---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Mike Mascari <mascarm@mascari.com> writes:[color=blue]
> Actually, I meant that setenv() and getenv() would only be used to
> store the memory address of a privately manipulated variable map. I
> did not mean that it should actually be used to store and retrieve the
> variables themselves. If there is already a way to palloc() memory
> using a key that lives for the lifetime of a backend, then that's
> obviously the way to go.[/color]

Plain old static pointer variable would do fine ... look for instance at
the remote-connections table in contrib/dblink/dblink.c.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

Mike Mascari wrote:
[color=blue]
> Tom Lane wrote:[/color]
[color=blue][color=green]
>>Uh, what exactly does it buy you to involve an environment variable
>>in this process? I think it just adds fragility. (For example,
>>exposing setenv to the user creates the risk that he'll overwrite
>>something of importance, like PATH.)[/color]
>
> Actually, I meant that setenv() and getenv() would only be used to
> store the memory address of a privately manipulated variable map. I
> did not mean that it should actually be used to store and retrieve the
> variables themselves. If there is already a way to palloc() memory
> using a key that lives for the lifetime of a backend, then that's
> obviously the way to go. I was proceeding under the assumption that
> there wasn't.[/color]

It's been a long time since I've used global variables. Sorry...

Mike Mascari
mascarm@mascari.com



---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)