Gaetano Mendola wrote:
Peter Eisentraut wrote:
Gaetano Mendola writes:
Some corrections.
I don't understand why your patch changes è to e' and à to a'. Also,
please make your next patch so that it can be applied to the file it.po
(not psql.pot).
Because with some terminal the character è,
Tom Lane wrote:
That was pretty much the argument that carried the day in the earlier
thread. However, I'm not sure how many people really use PQfnumber
(as opposed to hard-wiring assumptions about returned column numbers),
and it would seem that the intersection of those people with people who
u
Peter Eisentraut wrote:
There was a discussion on -interfaces that might need more consideration.
http://archives.postgresql.org/pgsql-interfaces/2003-09/msg00026.php
Apparently, it has so far been an undocumented feature of libpq's function
PGfnumber (return column number from column name) that
Dave Page wrote:
Hi,
In src/backend/parser/parse.h there is a copyright that reads as below.
Note the bottom section that says that the GPL is only excepted for
files generated by Bison *from* this file. This implies to me that this
file is GPL'd, and therefore shouldn't be in the tarball (or pgA
Bruce Momjian wrote:
Fact is, folks are doing it anyway by modifying pg_class. I know one
guy who did it in a transaction so he was the only one to see the
triggers disabled! The PostgreSQL cookbook page has an example too.
People are always asking how to do this. Why not just make it setable
Greg Stark wrote:
So a db designer made a bloody mistake.
Not necessarily. If I'm never going to update or delete from the parent table
the index would be useless. I find very few of my foreign key relationships
actually need indexes on the child table. I usually only have the unique i
Nigel J. Andrews wrote:
On Mon, 29 Sep 2003, Christopher Kings-Lynne wrote:
So a db designer made a bloody mistake.
The problem is there's no easy way to find out what's missing.
I'd really like EXPLAIN to display all subsequent triggered queries
also, to see the full scans caused by missing
Peter Eisentraut wrote:
Dave Page writes:
I find this a little worrying because if we want a feature or tweak for
pgAdmin we usually have to fight tooth & nail to justify getting it
committed (which is not a bad thing), however 'some guys at Red Hat' are
getting switches added to the postmaste
Christopher Kings-Lynne wrote:
Hi,
I notice that the pretty printing version of pg_get_ruledef inserts extra
newlines whereas all the others pretty functions (except view defs) do
not. In fact, Andreas argued against a version of pg_get_triggerdef()
that added extra newlines.
No, I did not *in g
Christopher Kings-Lynne wrote:
You could just as easily argue that the lack of integrity testing at
data load time was equally a bug.
I think we need someway of telling postgres to suppress a foreign key
check.
The main problem is that the foreign key column is often not indexed.
So a db desi
Tom Lane wrote:
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Surely the addresses can be assumed constant within a thread.
Otherwise we have a problem here too.
Quoting from the MSDN:
The address of a thread local object is not considered constant, and any
express
Christopher Kings-Lynne wrote:
I note there is no pretty printing option for pg_get_triggerdef...
Right.
There's no expression tree displayed, which would make the pretty print
option necessary.
As long as we don't have reengineering functions for *all* objects, it
doesn't make sense to impleme
Andrew Dunstan wrote:
Tom Lane wrote:
BTW, I've been wondering lately if we'd not be better off to look at
using threading in the Windows port, if it'd help us get around the
fork/exec data transfer problem. I'm not sure that it would, mind you,
but if it would give an answer it might be a lot l
Tom Lane wrote:
Robert Treat <[EMAIL PROTECTED]> writes:
On Wed, 2003-09-24 at 13:11, Bruce Momjian wrote:
SRA's Windows port is up to 7.3.4, and I think they just released
version 1.1, so that is going fine --- and I have the source code to
use in our native Win32 port, just not the threa
[EMAIL PROTECTED] wrote:
Tom Lane writes:
> The basic thing is to add an appropriate table entry to guc.c.
I take it there is not way to do this dynamically, for example to
support a dynamically loaded function? All runtime variables are
hard-coded into the backend?
Maybe you can implement your s
Jon Jensen wrote:
On Sat, 13 Sep 2003, Miko O'Sullivan wrote:
[EMAIL PROTECTED] (Jon Jensen) wrote in message news:<[EMAIL PROTECTED]>...
INSERT INTO sometable (5, <<\.
a
very long
string
\.
);
I'm delighted to hear that here docs are being discussed for postgres.
In the world of P
Terry Yapt wrote:
Hello all,
I have seen this presentation for new Novell Netware 6.5 version
released about two weeks or so.
http://www.novell.com/products/netware/netware65overview_popup.html
If you check 'Open Source' point, PostgreSQL text and PostgreSQL logo
are showed on the run.
I would b
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
I believe we could make
it a good deal more robust if both the opening and closing markers
(whatever they are) are required to stand alone on a line.
Hard to detect whitespace might trip things up. I wish
Sergio A. Kessler wrote:
Too sad, all special chars are used up for operators
also '{' '}' are used ?
I've only seen this in ACLs, so it might be usable. Tom, Bruce?
Regards,
Andreas
---(end of broadcast)---
TIP 6: Have you searched our list
Bruce Momjian wrote:
You mean if the special quotes are <-- and -->, <-> would be the
same as '-'?
If they work as the standard ' quote (and that seems to be Toms
intention), obviously.
Besides, we have to care specially about -->. Remember the complaints about
select 1--1,
behaving diffe
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Uh, the problem with long keywords is that you are then requiring the
_parser_ to identify those keywords, and at that point, the entire text
between the keywords has been sliced up by the lexer, which will
certainly make it a mess. I m
Bruce Momjian wrote:
Tom Lane wrote:
The discussion so far today seems to be entirely a rehash of arguments
already made (and in many cases already rebutted). Rather than wasting
list bandwidth with this, I think each camp ought to go off and do their
homework. Give us *details* of how your s
Richard Huxton wrote:
On Thursday 11 September 2003 09:33, Andreas Pflug wrote:
*NO PARSING*
The script must be stuffable into PQexec in total, backend does the rest.
Again: not psql, but sql language itself must provide this.
No out-of-band, because this would require splitting the script in
Andrew Dunstan wrote:
Tom Lane wrote:
Some people think a "sql syntax solution" is needed, and some do not.
So does this get resolved by a vote?
A "non-sql-syntax solution" is useless.
Regards,
Andreas
---(end of broadcast)---
TIP 1: subscrib
How is that relevant? It's still parseable with parameter placeholders in
place of literal parameters.
*NO PARSING*
The script must be stuffable into PQexec in total, backend does the rest.
Presumably \beginliteral \endliteral would be psql's way of specifying
parameters to ship over as paramet
Greg Stark wrote:
Could the function bodies be shipped over using the new FE protocol as
parameters? That would eliminate the quoting and simplify matters for DBI and
other drivers as well.
Oh no, not this discussion again.
A whole script containing any number of valid statements must be
execu
Alvaro Herrera wrote:
On Wed, Sep 10, 2003 at 10:35:18PM +0200, Andreas Pflug wrote:
I never agreed that a client solution would be satisfying. While
frontends might try to hide some uglyness of the syntax to the user for
single functions, editing large scripts with many functions is still
Andrew Dunstan wrote:
Alvaro Herrera wrote:
On Wed, Sep 10, 2003 at 07:04:13PM +0200, Andreas Pflug wrote:
Bruce Momjian wrote:
I assume we never came to a final conclusion on how to do CREATE
FUNCTION without double-quoting.
Many discussions, but no final conclusion in sight
Bruce Momjian wrote:
I assume we never came to a final conclusion on how to do CREATE
FUNCTION without double-quoting.
---
Many discussions, but no final conclusion in sight, it seems. That
\beginliteral stuff is psql centri
Tom Lane wrote:
Doug McNaught <[EMAIL PROTECTED]> writes:
I agree with another poster that deprecation in 7.4 and removal in
7.5 might make sense.
How would we "deprecate" it exactly? Throw a NOTICE?
Good question. A NOTICE just might be ignored, breaking everything
"surprisingly" in 7.
Tom Lane wrote:
Here are some possible responses, roughly in order of difficulty
to implement:
1. Leave well enough alone (and perhaps document the behavior).
2. Throw an error if the expression doesn't return boolean.
I'd opt for 2.
It's quite common that newer compilers will detect more bogus
Richard Huxton wrote:
Actually, a simple trace ability would be a huge step forward. It'd save me
dotting RAISE statements around my functions while I write them.
Sounds bloody familiar... :-(
Even the ability to add DEBUG statements that checked some global flag before firing
would be very us
The current implementation of plpgsql lacks some details that makes
programming really hard: there's no language validator to check the code
when creating the function, and there's support to debug the code.
Before I start hacking on this, I'd like to share my thoughts.
Looking at the code, I t
Gaetano Mendola wrote:
Work as non-root is a good practice for windows user too, I'll not bet
for the future that on windows all users will be "super user";
you can choose to start a service like a non super user too, I'd like to
mantain the same policy on windows too.
We're talking about
Bruce Momjian wrote:
We'll also need to decide the Windows equivalent of the 'don't run as
root' rule - or even if we want to enforce it at all, given that it
appears to be very common practice on Windows to run all services as a
user with Administrator privileges.
I assume we will relax t
Bruce Momjian wrote:
Greg Stark wrote:
It has nothing to do with MVCC. It has to do with implementing this is hard in
the general case.
Think of examples like:
select max(foo) group by bar;
or
select max(foo) where xyz = z;
To do it properly max/min have to be special-cased and tightly inte
Bruce Momjian wrote:
We have avoided doing dns lookups from pg_hba.conf, and hence the use of
127.0.0.1 instead of localhost. Now that we cache pg_hba.conf, we could
consider allowing hostnames in pg_hba.conf. Is that a TODO?
Hm. DNS lookup would make postmaster startup last much longer, to have
Andrew Dunstan wrote:
Andreas Pflug said:
Tommi Maekitalo wrote:
*nod* but it would be nicer if all loopback interfaces worked by
default - hence my localhost suggestion, which would match any of
127.0.0.1/32
:::127.0.0.1/128 and
::1/128
...
That sounds good. Is it possible
Darko Prenosil wrote:
On Wednesday 03 September 2003 00:55, Andreas Pflug wrote:
Darko Prenosil wrote:
Current bcc32.mak produces :
Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland
Error: Unresolved external '_pqGethostbyname' referenced from
D:\POSTGRESQL-7.
Tommi Maekitalo wrote:
*nod* but it would be nicer if all loopback interfaces worked by default
- hence my localhost suggestion, which would match any of
127.0.0.1/32
:::127.0.0.1/128 and
::1/128
cheers
andrew
...
That sounds good. Is it possible to extend lookup that way?
I'd feel
Darko Prenosil wrote:
Current bcc32.mak produces :
Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland
Error: Unresolved external '_pqGethostbyname' referenced from
D:\POSTGRESQL-7.4BETA2\SRC\INTERFACES\LIBPQ\RELEASE\BLIBPQ.LIB|getaddrinfo
Error: Unresolved external '_pqStrerror' referen
Tommi Maekitalo wrote:
Hi,
I doublechecked, that the patch applied. And there is a change. It workes for
connections from remote or to the ethernet-address, but not to localhost:
[EMAIL PROTECTED]:~ > export PGHOST=localhost
[EMAIL PROTECTED]:~ > psql -l
psql: FATAL: no pg_hba.conf entry for h
Czuczy Gergely wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
hello
i've tried to write a stored function in C++, using the libpq library, but
the g++(3.3.1) was unable to pass through the headers. there are a lot's
of reserved words used in structs as member names, such as delete,using,
na
Tommi Maekitalo wrote:
Hi,
the patch did not help.
Strange. Do you get a client side message "hba.conf entry for
::.127.0.0.1 missing"?
On my system the usual 127.0.0.1 255.255.255.255 is correctly converted to
:::127.0.0.1 ::::::255.255.255.255 and works
fine.
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
How about silently creating a IPV6 style host internally for every IPV4
pg_hba.conf entry? It won't make any sense to handle a real IPV4 address
different from an IPV4 address converted to IPV6 address space.
Hmm. I c
Tom Lane wrote:
Tommi =?iso-8859-15?q?M=E4kitalo?= <[EMAIL PROTECTED]> writes:
For remote connections I added:
host all all :::192.168.41.0/120trust
and it worked also (I guessed it - I don't know much about IPv6). Is
there any chance to get it work like 7.3
Tom Lane wrote:
Considering that someone earlier in this thread was specifically asking
to put LANGUAGE before the function body (apparently unaware that he
already could), I doubt we can get away with removing that flexibility.
I didn't consider *removing* flexibility, but *adding* flexibilit
Tommi Mäkitalo wrote:
Hi,
that worked for localhost. For remote connections I added:
host all all :::192.168.41.0/120trust
and it worked also (I guessed it - I don't know much about IPv6). Is there any
chance to get it work like 7.3? It is no nice experienc
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Why not regard anything between "AS" and LANGUAGE as source?
That seems quite impractical, considering that the function body may be
in a language that has little in common with SQL even at the lexical
level.
Tom Lane wrote:
What I don't like about this scheme is that it requires mods on both the
backend and client sides, to solve a problem that could be solved as
well or better (and definitely more simply) on the client side alone.
People are being misled by considering only psql, which is so stupid
t
Christopher Kings-Lynne wrote:
I have changed psql to use pg_get_viewdef(oid, true). I agree with Tom for
not using it in dumps just yet though.
While there still might be a pg_dump option to do this.
Is there a function for getting nice constraint defs?
Of course there is, use pg_get_constrain
Jeroen Ruigrok/asmodai wrote:
Check constraints: "bugs_severity_cstr" ((bug_severity =
'blocker'::character varying) OR (bug_severity = 'critical'::character
varying) OR (bug_severity = 'major'::character varying))
If you have even more choices there (as Bugzilla does) you even get:
CONSTRAINT bu
Dave Cramer wrote:
This just doesn't look right.
line 364
case COPY_NEW_FE:
while (datasize > 0 && !fe_eof)
line 408 datasize =- avail;
shouldn't it be datasize -= avail ?
AFAIR this is a really outdated K&R style of -= . Comp
Shridhar Daithankar wrote:
On 21 Aug 2003 at 9:21, Greg Stark wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Shridhar Daithankar wrote:
On 21 Aug 2003 at 0:22, Ian Barwick wrote:
* DDL
- Data definition language (table creation statements etc.) in MySQL
a
Shridhar Daithankar wrote:
On 21 Aug 2003 at 0:22, Ian Barwick wrote:
* DDL
- Data definition language (table creation statements etc.) in MySQL
are not transaction based and cannot be rolled back.
Just wondering, what other databases has transactable DDLs? oracle seems to
have autonomous
Bruce Momjian wrote:
2. SSL. Postmaster allows SSL for AF_INET but not AF_INET6.
This is fixed and works now.
Regards,
Andreas
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail co
Dann Corbit wrote:
-Original Message-
From: Andreas Pflug [mailto:[EMAIL PROTECTED]
Sent: Friday, August 15, 2003 11:36 AM
To: Dann Corbit
Cc: Stephan Szabo; PostgreSQL-development
Subject: Re: [HACKERS] [GENERAL] 7.4Beta
Dann Corbit wrote:
Simplification of bulk operations can be
Dann Corbit wrote:
Simplification of bulk operations can be very important for customers
(on the other hand). For the CONNX tool set, we offer an escape on
INSERT/SELECT that performs the operation in bulk mode.
There are serious downsides to bulk operations also (such as not being
logged and the
Stephan Szabo wrote:
I don't know if there will be or not, but in one case it's a single table
select with constant values, in the other it's probably some kind of scan
and subselect. I'm just not going to rule out the possibility, so we
should profile it in large transactions with say 100k single
Stephan Szabo wrote:
On Fri, 15 Aug 2003, Andreas Pflug wrote:
Stephan Szabo wrote:
On Fri, 15 Aug 2003, Andreas Pflug wrote:
Stephan Szabo wrote:
That really needs to be rewritten to do a single check over the table
rather than running the constraint for every row
Stephan Szabo wrote:
On Fri, 15 Aug 2003, Andreas Pflug wrote:
Stephan Szabo wrote:
That really needs to be rewritten to do a single check over the table
rather than running the constraint for every row. I keep meaning to get
around to it and never actually do. :( I'm not sure th
Stephan Szabo wrote:
On Fri, 15 Aug 2003, Christopher Kings-Lynne wrote:
I throw last nights backup at it. Data went in in about 1/2 an hour then
the
constraints went in and they took at age. about 2 hours.
Is there anyway to speed up the database constraint code? Because qui
Bruce Momjian wrote:
Still, if there's something not precise, it should be cleared. Which
tough assumptions are made that seem doubtful to you?
It just seemed complex to figure out which operators needed parens and
which didn't.
Only very-well-documented operators (Chapter 4.1.6) a
Christopher Browne wrote:
In an attempt to throw the authorities off his trail, [EMAIL PROTECTED] (Bruno Wolff III) transmitted:
On Fri, Aug 08, 2003 at 15:32:05 +0530,
Rahul_Iyer <[EMAIL PROTECTED]> wrote:
hi, im currently working on a project that requires batch
operations - eg. Batch i
Andrew Dunstan wrote:
Regarding second item, I don't think anyone suggested autodropping
objects, or else I misunderstood. (That would be dangerous, to say the
least, IMHO).
I agree, but some applications might use tables dedicated to a specific
user. While this is IMHO not a good style to us
Andrew Dunstan wrote:
I did have a thought that it could be done lazily (on backend startup)
on other databases and immediately on the current database. I guess it
depends on the cost of checking for such things - wouldn't want to add
greatly to startup time.
That would leave a small window of
I propose that the following should be added to the TODO list:
- expose read-only NEW/OLD rowsets in statement-level triggers that
represent the affected rows.
- Implement a way to enable triggers to check which columns are affected
by the triggering statement.
Regards,
Andreas
-
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Only very-well-documented operators (Chapter 4.1.6) are parens-optimized
(+-*/%);
At the moment ... but you can be sure there will be demand to get smarter.
I never claimed to implement the ultimate solution, just
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
It just seemed complex to figure out which operators needed parens and
which didn't.
The fact that the first attempt was wrong doesn't improve my faith in
that code one bit ;-).
It was posted expressiv
Tom Lane wrote:
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
But should the CREATE DOMAIN manual page refer to DROP TYPE? Should DROP
DOMAIN be able to drop a type?
Don't care much about either of those; the current state of
affairs is fine with me.
What happens in the future
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
I wonder why you are suggesting workarounds for features that other
databases provide.
The fact that other databases provide 'em doesn't make them good ideas.
In particular, writing a trigger that assumes that
Bruce Momjian wrote:
How are statement level triggers supposed to work? Are they just
triggers deferred until the end of the statement? You mentioned access
to the affected rows, but I don't understand how that is supposed to
happen.
Statement level isn't about deferring or grouping the trigg
Neil Conway wrote:
On Mon, Aug 04, 2003 at 10:47:36AM +0200, Andreas Pflug wrote:
AFAICS the current implementation still doesn't have a way to access the
affected rowset, so it'a pretty much like a SELECT without a WHERE.
Yeah, unfortunately I didn't get a chance to
Bruce Momjian wrote:
Tom Lane wrote:
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
It might be a bit risky getting pg_dump to use it though?
I definitely don't want pg_dump using the pretty-print stuff ;-).
I'm neutral on whether to use it in psql's \d commands.
I thought
I'm not sure this is a fair assessment of statement level triggers.
Yes, in MSSQL you can access the rows involved in the statement, but
in Oracle you cannot (emphasis added):
"Accessing Column Values in Row Triggers
Within a trigger body of a *row trigger*, the PL/SQL code and SQL
statements
Tom Lane wrote:
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
So if you agree that there is a quoting problem,and you don't mind
breaking backwards compatibility for it, I'll do a complete patch...
I don't see any backwards-compatibility issue, because usernames
containing double quo
Bruce Momjian wrote:
It might be a bit risky getting pg_dump to use it though?
I don't think we every want pg_dump to use it --- better accurate than
pretty in there.
Agreed.
There seems to be some tough assumptions that have to
be made in that function that are better used for visual-only c
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
This can already be done by comparing old and new values, no?
No, this is not the case.
UPDATE foo SET x=x, y=y
is different from
UPDATE foo SET y=y
if triggers maintaining x are involved.
vailable...
Regards,
Andreas
Bruce Momjian wrote:
Do you have suggested wording?
-------
Andreas Pflug wrote:
Bruce Momjian wrote:
Here are the changes for 7.4. I am looking for any improvements. This
will
Bruce Momjian wrote:
Andreas Pflug wrote:
YATS (yet another TODO suggestion):
provide an official and reliable way to temporarily enable/disable triggers.
"ALTER TABLE xxx ENABLE/DISABLE TRIGGER ALL/trgName"
We still have that nasty "not presently checked everywhere it should
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Consider this:
Table with one column that is maintained by a trigger for this rule:
- Only one row in a group of rows may have a foo-value of "true", all
others must be "false".
- If foo=true is inserted/upda
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
- Implement a way to enable triggers to check which columns are affected
by the triggering statement.
This can already be done by comparing old and new values, no?
No, this is not the case.
UPDATE foo SET x=x, y=y
is dif
Joe Conway wrote:
Andreas Pflug wrote:
But PostgreSQL may be better than Oracle, don't you think? In the
named document,
MSSQL2000 still doesn't have row level triggers, and I doubt that
2003 has.
Right, so as you've pointed out, Postgres trigger implementation is at
lea
Bruce Momjian wrote:
Here are the changes for 7.4. I am looking for any improvements. This
will be adjusted as we move through beta.
---
Add FOR EACH STATEMENT statement-level triggers (Neil Conway)
AFAICS the current implem
We wouldn't like to have it called Ingres too...
Spoken language is different from written, so docs should be precise.
PostgreSQL is a mark, and should be used as careful as it deserves.
Regards,
Andreas
Christopher Kings-Lynne wrote:
I just seem to recall a discussion where we decided to 'stand
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
I just checked out (at the moment hba.c changed, so I had to redo it),
make clean, make, pgsql stop, make install, pgsql start and it's still
there.
It works fine for me too. Try removing
src/backend/parser/gra
Joe Conway wrote:
Andreas Pflug wrote:
The current snapshot won't initdb, because running
information_schema.sql fails.
The two occurences of "WHERE u.usesysid = ANY( g.grolist )" are the
problem. Replacing the ANY clause with some dummy will let everything
run ok.
sele
The current snapshot won't initdb, because running
information_schema.sql fails.
The two occurences of "WHERE u.usesysid = ANY( g.grolist )" are the
problem. Replacing the ANY clause with some dummy will let everything
run ok.
select usename from pg_user, pg_group where usesysid = ANY (grolist)
Bruce Momjian wrote:
I usually do it, but it might take a week to put together.
---
Robert Treat wrote:
Once you folks are done going through the remaining list of patches, can
we get someone to send a rough list of new f
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
pg_get_indexdef converts that string to a list of nodes (not
surprising), while pg_get_expr whill join these list elements with an
explicit and (according to a comment, needed for partial index). Do I
need to retrieve indexp
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
I noticed the new expression functionality of indices and while
implementing them in pgadmin3 was wonderingnow to extract the definition
from the catalog.
The best way is to use pg_get_indexdef(indexOID), same as pg_dump an
I noticed the new expression functionality of indices and while
implementing them in pgadmin3 was wonderingnow to extract the definition
from the catalog.
Consider an index that looks like this:
CREATE INDEX foo ON bar (numcol, length(txtcol), intcol2,
length(txtcol2))
Looking at pg_index:
Francisco Figueiredo Jr. wrote:
Hi all,
I'm getting the following error when trying to do an initdb:
This user must also own the server process.
initializing pg_depend... ERROR: expression_tree_walker: Unexpected
node type 601
IN: expression_tree_walker (clauses.c:2320)
Hi Francisco,
I had
Bruce Momjian wrote:
OK, added to TODO:
Modify pg_get_triggerdef() to take a boolean to pretty-print,
and use that as part of pg_dump along with psql
Andreas, can you work on this? I like the idea of removing extra
parens, and merging it into the existing code rather than into co
johnn wrote:
On Wed, Jun 25, 2003 at 10:30:31AM -0500, Andrew Dunstan wrote:
DB2 looks good. I have horrid, horrid memories of wrestling with the
Oracle "extent" madness.
I do think that it's worth providing additional access points to
tablespaces, though. That is, it would make sense
Jan Wieck wrote:
Change that into "* Remove bugs from source code" and get a patent on
it. Should be a nobrainer (as in those guy's have no brains)
considering that NetFlix even got a patent on DVD subscription rentals:
http://slashdot.org/article.pl?sid=03/06/24/1458223&mode=flat&tid=155&tid=9
Christopher Kings-Lynne wrote:
I was considering adding this and the stuff Andreas requested to
pg_settings (but not "SHOW ALL" or "SHOW x" unless people feel it's
important to kept them consistent with pg_settings). Were the Red Hat
guys going to do this?
pg_settings would be fine for php
Bruce Momjian wrote:
I don't think an option to do such justification would be good unless we
can do it consistenly in the code, and there is enough demand.
It's no big additional effort to do this, and going back and forth is
not a big problem. I wouldn't invent an option for that, just do it.
Rod Taylor wrote:
Oh, one more thing --- right justify isn't as accepted as left-justify
But it looks so much better...
Ye!
Consider this:
SELECT foo
FROM bar b
LEFT JOIN chair c USING (thekeycol)
WHERE ...
:-)
versus
SELECT foo
FROM bar b
LEFT JOIN chair c USING (thekeycol)
WHE
Bruce Momjian wrote:
OK, added to TODO:
Modify pg_get_triggerdef() to take a boolean to pretty-print,
and use that as part of pg_dump along with psql
Andreas, can you work on this? I like the idea of removing extra
parens, and merging it into the existing code rather than into
401 - 500 of 518 matches
Mail list logo
