On Thu, 2003-06-05 at 14:16, Josh Berkus wrote:
> Rod,
>
> > > 4) Does anyone else have any comments on the proposed re-ordering?
> >
> > Since we're painting a shed, does it make sense to put the items in
> > alphabetical order for each section?
>
> I thought about that, yes. However, I find
Is there any ETA for cvs?
Dave
--
Dave Cramer <[EMAIL PROTECTED]>
fastcrypt
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
On Thu, Jun 05, 2003 at 09:44:21AM -0600, scott.marlowe wrote:
> On Thu, 5 Jun 2003, Nigel J. Andrews wrote:
> Everything Nigel just wrote plus one thing.
>
> If it comes down to it, we could always require a --locale setting and
> refuse to initdb without it. That way, whether it's in an RPM o
Rod Taylor <[EMAIL PROTECTED]> writes:
> It would seem a new primnode (change InsertDef into SetDefault or
> similar) will be required with some executor logic.
It is not the executor's business to know about defaults. The rewriter
is the place where defaults get inserted - see rewriteTargetList(
Rod,
> > 4) Does anyone else have any comments on the proposed re-ordering?
>
> Since we're painting a shed, does it make sense to put the items in
> alphabetical order for each section?
I thought about that, yes. However, I find that most items have a logical
order that is not alphabetical.
On Thu, 2003-06-05 at 16:45, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > It would seem a new primnode (change InsertDef into SetDefault or
> > similar) will be required with some executor logic.
>
> It is not the executor's business to know about defaults. The rewriter
> is the p
On Thu, 5 Jun 2003, Peter Eisentraut wrote:
> scott.marlowe writes:
>
> > If it comes down to it, we could always require a --locale setting and
> > refuse to initdb without it. That way, whether it's in an RPM or from
> > source, somebody somewhere along the line has to choose something.
>
> B
Srikanth M <[EMAIL PROTECTED]> writes:
> Could anyone tell me where excatly the result of a query is stored
> after the query is passed to pg_exec_query_string function and before it
> is printed.
It isn't "stored" anywhere --- tuples are passed to the frontend as they
are generated.
scott.marlowe writes:
> If it comes down to it, we could always require a --locale setting and
> refuse to initdb without it. That way, whether it's in an RPM or from
> source, somebody somewhere along the line has to choose something.
By default, you choose when you install or configure your op
The recent change to make log_min_messages SUSET provokes the following
behavior:
$ export PGOPTIONS="-d 5"
$ psql
psql: FATAL: 'log_min_messages': permission denied
$
Considering that I *am* superuser, this is quite unacceptable.
If you don't want to revert the change, propose another solution.
scott.marlowe writes:
> If indexes on text worked right in other locales it would be no big deal.
They will in version 7.4, so all these concerns about trading off locale
use vs. performance will become obsolete.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broad
On Thu, 2003-06-05 at 11:11, Rod Taylor wrote:
> On Wed, 2003-06-04 at 22:28, Christopher Kings-Lynne wrote:
> > > Which ones are missing, and should we really be looking at creating
> a
> > > pg_definition_schema instead?
> >
> > Missing:
> >
> > Database, schema, table, domain, cast, conversion
On Fri, 6 Jun 2003, Tom Lane wrote:
> "Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> > Now, I did a little bit of testing and when doing a \lo_export
> > in psql connected via localhost a SIGPIPE is generated in
> > write() in libc and psql quit, without printing any message to the
> > termina
"Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> Now, I did a little bit of testing and when doing a \lo_export
> in psql connected via localhost a SIGPIPE is generated in
> write() in libc and psql quit, without printing any message to the
> terminal. Perhaps interestingly
> the file that gets
I've gotten back to working on the SQL99 version of updateable views and
I'ld like to confirm my current understanding of the parse tree data
structure. Is there a debugging-type tool for outputting the parse tree for
a given query?
Eric Nielsen
---(end of broadcast)-
--On Saturday, June 07, 2003 10:42:31 -0500 Larry Rosenman <[EMAIL PROTECTED]>
wrote:
cc -O -g -I../../../src/interfaces/libpq -I../../../src/include
-I/usr/local/include -DBINDIR=\"/usr/local/pgsql/bin\" -c -o pg_dump.o
pg_dump.c UX:cc: WARNING: debugging and optimization mutually exclusive;
-O d
I kind of prefer the way things were grouped together in 7.2 vs. 7.3. If I
needed to check out connection information or look at query tuning flags,
they were all right next to each other and I didn't have to scroll back and
forth through the list. Luckily most of the topical variables share so
cc -O -g -I../../../src/interfaces/libpq -I../../../src/include
-I/usr/local/include -DBINDIR=\"/usr/local/pgsql/bin\" -c -o pg_dump.o
pg_dump.c UX:cc: WARNING: debugging and optimization mutually exclusive; -O
disabled UX:acomp: ERROR: "pg_dump.c", line 192: incomplete
struct/union/enum option: l
Repost just to add the information that this is [now] on 7.3.3, previously on
7.3.2.
Sorry for the noise of the incomplete previous message, although the email
lists seem to be very light this last week. Obviously the mail server is still
feeling under the weather, I presume many posts have been
Eric D Nielsen <[EMAIL PROTECTED]> writes:
> I've gotten back to working on the SQL99 version of updateable views and
> I'ld like to confirm my current understanding of the parse tree data
> structure. Is there a debugging-type tool for outputting the parse tree for
> a given query?
See debug_pri
Note, primary list address changed to -general, I'd suggest any followups
remove the -hackers, which I've left in just for 'closure'.
On Fri, 6 Jun 2003, Nigel J. Andrews wrote:
> On Fri, 6 Jun 2003, Tom Lane wrote:
>
> > "Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> > > Now, I did a little
Josh Berkus <[EMAIL PROTECTED]> writes:
> "wal_debug" is seldom used outside of Postgresql source development or unusual
> system failures, and should therefore go last.
BTW, it occurs to me that wal_debug is one of the hacker-only variables
that probably ought not be documented at all. I cannot
?? cvs itself has been working for ages now ... anoncvs isn't ... or is
that what you are using?
On Thu, 5 Jun 2003, Dave Cramer wrote:
> Is there any ETA for cvs?
>
> Dave
> --
> Dave Cramer <[EMAIL PROTECTED]>
> fastcrypt
>
>
> ---(end of broadcast)
Does the SQL(99?) spec specify that referential integrity checks should have
the FROM ONLY limitation? I ask because(afiak; I've googled and such, only found 92
which apparently does not specify anything about inheritance.) I have no access to the
specs without spending money th
Hi all,
I wonder if it's a security problem: One of my customer noticed that he
could see all databases on the system with phppgadmin. not only he sees
databases but tables, views, fonctions... Fortunatly he can't see any row.
This customer has the ability to create databases but not users.
I won
I think people thought if you were doing SHOW ALL, you were looking for
a specific variable, so alphabetical was best.
---
Robert Treat wrote:
> On Thu, 2003-06-05 at 11:23, Josh Berkus wrote:
> >
> > 4) Does anyone else ha
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> ... Therefore I ask whether everyone agrees
> that groups and roles are basically equivalent concepts (and perhaps that
> we might in the future strive to make groups more compatible with the
> roles as defined in the SQL standard). Or does anyone see
Robert Treat <[EMAIL PROTECTED]> writes:
> I think this was touched on before, but was there a final determination
> of the ordering of the "show all" command?
SHOW ALL will remain alphabetical.
regards, tom lane
---(end of broadcast)--
28 matches
Mail list logo
