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
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
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
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
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
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
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
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
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
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
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
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
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
13 matches
Mail list logo
