Gavin Sherry wrote:
> This just clears up one aspect of variable handling in psql.
> [ "variable names are case-sensitive" ]
I honestly wonder why this is suddenly of so much interest. I hope no
one is going to question the fact that the command names are
case-sensitive. Do we need a note abou
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Gavin Sherry wrote:
>> This just clears up one aspect of variable handling in psql.
>> [ "variable names are case-sensitive" ]
> I honestly wonder why this is suddenly of so much interest.
I think it's reasonable to document the behavior, especially
On Tue, 10 Feb 2004, Peter Eisentraut wrote:
> Gavin Sherry wrote:
> > This just clears up one aspect of variable handling in psql.
> > [ "variable names are case-sensitive" ]
>
> I honestly wonder why this is suddenly of so much interest. I hope no
> one is going to question the fact that the co
Using schemas is fun. Setting the search_path every time I use psql
isn't. This patch modifies startup.c in psql to allow the SEARCH_PATH
to be set to whatever the PG_SCHEMA_SEARCH_PATH environment variable is
set to. If the var is not defined or is empty, no action is taken and
the search path
Kris Jurka wrote:
>
> http://developer.postgresql.org/docs/postgres/datatype.html#DATATYPE-NUMERIC
>
> Section 8.1.1 has not been updated to reflect the recent addition of
> indexes which can be used across type definitions.
>
> Kris Jurka
This patch was applied by Tom:
revisio
Scott Goodwin wrote:
Using schemas is fun. Setting the search_path every time I use psql
isn't. This patch modifies startup.c in psql to allow the SEARCH_PATH to
be set to whatever the PG_SCHEMA_SEARCH_PATH environment variable is set
to. If the var is not defined or is empty, no action is taken
Hi Chris,
No, I didn't know that, but I figured there might be another, better
way to do this that I hadn't found. Thanks for the info; I'm going to
dig into ALTER USER to see what else I may be missing. Consider this
patch "rescinded", though it was a good exercise in working with PG
source c
Mark Feit wrote:
> This patch against 7.4.1's psql and the documentation adds the option
> of reading rows from the "current" input stream (standard input, -f
> xxx, \i xxx) during a "\copy ... from" operation in psql. The details
> were proposed and discussed (somewhat) here:
>
> http://archiv
No, I didn't know that, but I figured there might be another, better way
to do this that I hadn't found. Thanks for the info; I'm going to dig
into ALTER USER to see what else I may be missing. Consider this patch
"rescinded", though it was a good exercise in working with PG source
code. If any
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Do you know that you can go ALTER USER yourselft SET SEARCH_PATH TO
> "'public','core','objects'"; So that will always be your default path?
Another possibility is to issue the SET from a ~/.psqlrc file (I think
that's what it's called, check
On Feb 10, 2004, at 9:51 AM, Christopher Kings-Lynne wrote:
I have the feeling it wouldn't have been accepted because it was kind
of 'arbitrary'. It's generally a good idea to ask the -hackers list
first if a patch is worth writing before actually writing it ;)
Ah well, it was worth the experie
Scott Goodwin <[EMAIL PROTECTED]> writes:
> If anyone cares to, I'd still like feedback on anything I could have
> done better in this patch
Since, you asked, two minor points: (1) palloc() is for memory
allocation in the backend; use malloc() (or a wrapper like
pg_malloc()) in frontend apps and l
Hi Neil,
I also saw an mm_alloc or something similar in another area of code.
I'll spend some time reading through the sources properly before I
attempt another mod. Thanks for the feedback -- much appreciated.
/s.
On Feb 10, 2004, at 3:24 PM, Neil Conway wrote:
Scott Goodwin <[EMAIL PROTECTE
13 matches
Mail list logo