-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Apr 26, 2008 at 5:08 PM, Bryce Nesbitt
wrote:
> Well, come to think of it, "wrapped" is not really a new output format in
> the sense of "html" or "latex". It could build on aligned:
>
> \pset format aligned [autowrap|nowrap|nnn]
>
I agree
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Apr 26, 2008 at 4:13 PM, Andrew Dunstan wrote:
>
> Before you come trolling on this (or any other) subject, please read the
> voluminous debates that have taken place about it. Apparently you think it's
> something we have never considered, w
Raphaël Jacquot wrote:
would seem like a good idea, no ?
http://www.murrayc.com/blog/permalink/2008/04/25/postgresql-has-no-bugzilla/
Before you come trolling on this (or any other) subject, please read the
voluminous debates that have taken place about it. Apparently you think
it's some
Hello All.
Now I try to link dll with MinGW from Example in Postgres Help.
Linker show me this error:
D:\users\anthony\kursor\abzcrm\c\foo>gcc -shared foo.o -o foo.dll -L
"d:/files/local/PostgreSQL/8.3/lib" -l postgres
Cannot export ⌂postgres_NULL_THUNK_DATA: symbol not found
collect2: ld retu
Bruce Momjian wrote:
Hey, I can work with this idea. First, there really is no 'off' mode
for wrapped because that is aligned...
Well, come to think of it, "wrapped" is not really a new output format
in the sense of "html" or "latex". It could build on aligned:
\pset format aligned [autowrap|
[Just when I thought I was out, they pull me back in -- argh, I'm weak]
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> FYI, ls -C actually wraps to 72(?) unless you specify another width,
I told you exactly what ls did, at least GNU ls. It uses -w if specified, if
not then it uses the ioctl if
would seem like a good idea, no ?
http://www.murrayc.com/blog/permalink/2008/04/25/postgresql-has-no-bugzilla/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi,
One of the few parts of the core that is not localized is the ecpg.
Attached is a patch that builds the basic infrastructure to make it
possible. Besides that I worked on some strings to make them conform
with [1] but I didn't do for all of them.
When I was doing the clean up I realized th
Bryce Nesbitt wrote:
> But I agree it's not desirable to wrap file any sort of stream output,
> by default, as that would break just about any script known to mankind.
> Yet wrapping is a very user-friendly default for interactive terminals.
> This is potentially an irreconcilable inconsistency
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Apr 26, 2008 at 11:02 AM, stephen layland wrote:
> I've written a quick patch against the head branch (8.4DEV, but it also
> works with 8.1.3 sources) to fix LDAP authentication support to
> work with LDAPS servers that do not need start TL
Am Samstag, 26. April 2008 schrieb Bryce Nesbitt:
> But that leaves a big hole: what does the setting in .psqlrc refer to?
> Do we need separate controls in .psql?
>
> \pset format_terminal wrap [auto|nnn|off]
> \pset format_terminal html
> \pset format_stream wrap [auto|nnn|off]
> \p
As the originator of the "psql wraps at window width" patch, I'd like to
set a matter or two straight:
The ioctl() function does not fail under ssh, contrary to the assertion
made several times. Nor does $COLUMNS remain static if the window size
changes. $COLUMNS is not a property of a bash,
Hey Postgres Hackers,
this is my first time here, so... hi!
I've written a quick patch against the head branch (8.4DEV, but it also
works with 8.1.3 sources) to fix LDAP authentication support to
work with LDAPS servers that do not need start TLS. I'd be interested
to hear your opinions on this
Hi all,
Quick question: is there currently a way to see how many slot are
used in the FSM (i.e. how many free pages are stored there), or how
many are free? If not, wouldn't it be a good idea to add this
somewhere? (Don't quite know where... is it possible to have very
dynamic values in show
"Tom Dunstan" <[EMAIL PROTECTED]> writes:
> On Sat, Apr 26, 2008 at 2:51 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> Further, as already noted, if you do have to rewrite then a series of
>> manual ALTER COLUMN TYPE operations would probably be a *better* answer
>> than a monolithic implementation, b
On Sat, Apr 26, 2008 at 2:51 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> I'm not ... it strikes me that it will add implementation complexity and
> runtime overhead for a feature that two days ago we didn't think we
> needed at all, and IMHO one we still shouldn't be thinking to expend a
> lot of
Tom Dunstan wrote:
So two alternative proposals, both with a 2 byte "enum id" and a 2 byte "value":
1 - We space the values out as evenly as we can across the 65000ish
range and allow people to delete, insert and append, but not reorder.
If they do the above gratuitously we might have to do a
Alvaro Herrera wrote:
> Bruce Momjian escribi?:
>
> > Obviously you have expections of how wrapping should behave. Please
> > name me an application that has a wrapped mode that has the output to a
> > file wrap based on the screen width? It isn't 'ls -C'.
>
> Why would we need to imitate what
"Tom Dunstan" <[EMAIL PROTECTED]> writes:
> 1 - We space the values out as evenly as we can across the 65000ish
> range and allow people to delete, insert and append, but not reorder.
> If they do the above gratuitously we might have to do a rewrite, but
> they'll have to get fairly busy to do it.
Oops, sorry for the crossed emails, slight delay in my main being received.
On Sat, Apr 26, 2008 at 2:18 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> I think with something like your 16bit/16bit design, and say ten free
> codes between each original assignment, it'd be okay to not support the
> re
On Sat, Apr 26, 2008 at 2:07 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> > The very first idea that I had was to have an enum value as
> > the combination of both an enum id and the ordinal value.
>
> I seem to remember that we discussed that and rejected it, but I don't
> remember the reasoning.
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> On Sat, Apr 26, 2008 at 6:33 AM, Tom Dunstan wrote:
>> I've already suggested some alternatives in the reply to Brendan that
>> would solve some of this, but I suppose another gross-seeming way to
>> stop surprise rewrites would be to never do one unles
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Apr 26, 2008 at 6:33 AM, Tom Dunstan wrote:
> One scenario I'm not happy about is this: the friendly db admin has
> happily added an extra value to the end before and the operation has
> been a snap - no rewriting required. But this time ei
"Tom Dunstan" <[EMAIL PROTECTED]> writes:
> One scenario I'm not happy about is this: the friendly db admin has
> happily added an extra value to the end before and the operation has
> been a snap - no rewriting required. But this time either a) oid
> wraparound has occurred, b) she's inserted one
>>> On Fri, Apr 25, 2008 at 3:14 PM, in message
<[EMAIL PROTECTED]>, "Brendan
Jurd"
<[EMAIL PROTECTED]> wrote:
> If the user hasn't specified any format at all, then it's fine to
play
> guessing games and try to select the best format automatically for
> him, based on factors like the destinati
"Tom Dunstan" <[EMAIL PROTECTED]> writes:
> I wonder if it's worth revisiting the decision to save enums on disk
> as oids. The very first idea that I had was to have an enum value as
> the combination of both an enum id and the ordinal value. We would
> presumably make both say 16bits so we could
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Apr 26, 2008 at 6:19 AM, Tom Dunstan wrote:
> I wonder if it's worth revisiting the decision to save enums on disk
> as oids. The very first idea that I had was to have an enum value as
> the combination of both an enum id and the ordinal v
On Fri, Apr 25, 2008 at 11:57 PM, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
> We already support rewriting tables ... (albeit only one at a time, I
> admit. Doing it for more than one can cause deadlocks).
>
> Still, if the user wants to pay the cost, why should we prohibit it?
One scenario I'
Brendan Jurd escribió:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Sat, Apr 26, 2008 at 6:02 AM, Tom Lane wrote:
> > "Brendan Jurd" writes:
> > > Has anyone had a close look at how hard it would be allow just the
> > > "add to the end" capability?
> >
> > The problem is you can't
On Sat, Apr 26, 2008 at 12:10 AM, Brendan Jurd <[EMAIL PROTECTED]> wrote:
> Has anyone had a close look at how hard it would be allow just the
> "add to the end" capability?
If the OIDs haven't wrapped around since the enum was created, it's
trivial. If they have, well someone with more OID-fu t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Apr 26, 2008 at 5:21 AM, Bruce Momjian
wrote:
> Obviously you have expections of how wrapping should behave. Please
> name me an application that has a wrapped mode that has the output to a
> file wrap based on the screen width? It isn't
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> There is no point in doing things in a certain way just because others
> do the same. Are you going to argue that we need to make the server
> crash from time to time because other systems do that too?
> We came up with dollar quoting which is a comple
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Apr 26, 2008 at 6:02 AM, Tom Lane wrote:
> "Brendan Jurd" writes:
> > Has anyone had a close look at how hard it would be allow just the
> > "add to the end" capability?
>
> The problem is you can't guarantee anything about the ordering of
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> Has anyone had a close look at how hard it would be allow just the
> "add to the end" capability?
The problem is you can't guarantee anything about the ordering of the
new value relative to the old ones. The OID it's assigned might be
after them, or be
Bruce Momjian escribió:
> Obviously you have expections of how wrapping should behave. Please
> name me an application that has a wrapped mode that has the output to a
> file wrap based on the screen width? It isn't 'ls -C'.
Why would we need to imitate what other apps do? What we need to
inve
Brendan Jurd wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Sat, Apr 26, 2008 at 4:46 AM, Gregory Stark wrote:
> > If you specify format=wrapped and get something other than wrapped it's a
> > bug
> > and people will undoubtedly report it as such.
> >
>
> Agree. If I tell ps
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Apr 26, 2008 at 4:46 AM, Gregory Stark wrote:
> If you specify format=wrapped and get something other than wrapped it's a bug
> and people will undoubtedly report it as such.
>
Agree. If I tell psql that I want wrapped output and it gives
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
>> I think the people wanting wrapped to control file/pipe don't want it as
>> the default, but want _some_ way of getting wrapped output into a file.
>
> Let me add that the patch as it was posted does not have wrapping
> affecting file/pipe output unle
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Apr 26, 2008 at 4:27 AM, Alvaro Herrera wrote:
> Andrew Dunstan wrote:
> >
> > Bruce Momjian wrote:
> >> Log Message:
> >> ---
> >> Update:
> >>
> >> >>
> >>> * Allow adding/removing enumerated values to an existing enumerate
Andrew Dunstan wrote:
>
> Bruce Momjian wrote:
>> Log Message:
>> ---
>> Update:
>>
>> < * Allow adding enumerated values to an existing enumerated data
>>
>>> * Allow adding/removing enumerated values to an existing enumerated data
>
> Where did this come from? Adding values anywhere ex
On Thursday 24 April 2008 23:40, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > Perhaps a better option would be to implement Merge per spec, and then
> > implement a "replace into" command for the oltp scenario. This way you
> > keep the spec behavior for the spec syntax, and have
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Bruce Momjian escribi?:
> >
> > > Have a 'format=auto' mode that does aligned/wrapped/expanded, but only
> > > for screen output --- file/pipe would still use aligned. And have
> > > 'format=wrapped' affect file/pipe by requiring the user to specif
Alvaro Herrera wrote:
> Bruce Momjian escribi?:
>
> > Have a 'format=auto' mode that does aligned/wrapped/expanded, but only
> > for screen output --- file/pipe would still use aligned. And have
> > 'format=wrapped' affect file/pipe by requiring the user to specify the
> > width, or use a default
On Fri, 25 Apr 2008 10:45:01 -0400
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> I have a different question. Why are we mixing file and pipe
> output? I think the use cases are different and perhaps we should
> use different defaults.
>
> For example, most people I've seen writing shell script
Bruce Momjian escribió:
> Have a 'format=auto' mode that does aligned/wrapped/expanded, but only
> for screen output --- file/pipe would still use aligned. And have
> 'format=wrapped' affect file/pipe by requiring the user to specify the
> width, or use a default of 72.
I have a different questi
Bruce Momjian wrote:
> We have discussed having a formatting mode where aligned output switches
> to expanded output when the row is too wide. One idea would be to
> create an 'auto' mode that would display in aligned, or wrapped if that
> doesn't fit, or expanded if that doesn't fit.
I haven't h
Simon Riggs wrote:
> I'm now happy that we can get a spec-compliant end result by always
> forcing NOT MATCHED rules to occur before MATCHED rules, when we have at
> least one unique index.
... and raise an ERROR when there is no unique index?
--
Alvaro Herreraht
Robert Treat wrote:
Perhaps a better option would be to implement Merge per spec, and then
implement a "replace into" command for the oltp scenario. This way you keep
the spec behavior for the spec syntax, and have a clearly non-spec command
for non-spec behavior.
MySQL's "REPLACE IN
* Bruce Momjian <[EMAIL PROTECTED]> [080424 23:14]:
> Well, I was going to bring up changes to the default after the patch was
> applied but I will bring it up now. I think there is some real
> attractivness to having long values wrap to fit on your screen in
> interactive mode. In fact, it is
On Fri, 2008-04-25 at 10:03 +0300, Hannu Krosing wrote:
> On Tue, 2008-04-22 at 00:24 +0100, Simon Riggs wrote:
> > On Mon, 2008-04-21 at 16:38 -0400, A.M. wrote:
> >
> > > "MERGE will not invoke Rules." Does this imply that MERGE cannot be
> > > used on views or that the resulting INSERTs or UP
On Apr 25, 2008, at 3:28 AM, Simon Riggs wrote:
I recently came across the expression "YAGNI", and think it's
probably
pretty relevant to this discussion:
http://en.wikipedia.org/wiki/You_Ain't_Gonna_Need_It
In matters of technical implementation, I follow you almost without
question, and ver
On Thu, 2008-04-24 at 20:28 +0100, Simon Riggs wrote:
> With MERGE, we would need to do it like this:
>
> 1. If there are any WHEN NOT MATCHED clauses that trigger INSERTs, then
> attempt to apply them first, no matter what order they were in with
> respect to the WHEN MATCHED clauses. Start loop
On Fri, 2008-04-25 at 11:07 +0200, Petr Jelinek wrote:
> Another thing is, the table on which we do SELECT (the one in USING) can
> be different from target table and we can use columns from that table in
> INSERT/UPDATE statement (probably one the reasons why spec says the
> "SELECT" query has
Tom Lane wrote:
Robert Treat <[EMAIL PROTECTED]> writes:
Perhaps a better option would be to implement Merge per spec, and then
implement a "replace into" command for the oltp scenario. This way you keep
the spec behavior for the spec syntax, and have a clearly non-spec command
for non-spec b
On Thu, Apr 24, 2008 at 11:40:22PM -0400, Tom Lane wrote:
> In that case, it's a fair question to ask just who will use the "spec"
> syntax. As far as I can tell from years of watching the mailing lists,
> there is plenty of demand for a concurrent-safe insert-or-update
> behavior, and *exactly ze
On Thu, 2008-04-24 at 23:40 -0400, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > Perhaps a better option would be to implement Merge per spec, and then
> > implement a "replace into" command for the oltp scenario. This way you
> > keep
> > the spec behavior for the spec syntax,
On Tue, 2008-04-22 at 00:24 +0100, Simon Riggs wrote:
> On Mon, 2008-04-21 at 16:38 -0400, A.M. wrote:
>
> > "MERGE will not invoke Rules." Does this imply that MERGE cannot be
> > used on views or that the resulting INSERTs or UPDATEs do not work on
> > views?
>
> Yes, that's right. Just li
57 matches
Mail list logo
