Re: [HACKERS] Tech details - psql wraps at window width
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|nowrap|nnn] But there's still the issue of wanting separate defaults for tty and stream outputs. The last thing you want is an admin deciding on wrapping, and then subtly breaking scripts. My personal desired defaults are: * Terminals autowrap. * Streams don't wrap, except in the rare case when I want to force a specific width (e.g. 79 for a newsgroup posting). -Bryce -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Compiling trigger function with MinGW
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\foogcc -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 returned 1 exit status What should I do? -- Anton Burkun +380 66 757 70 27 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] we don't have a bugzilla
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 something we have never considered, which in light of the product we maintain would be more than remarkable. Having done that, please endeavour to make an actual contribution to the discussion. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] we don't have a bugzilla
-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, which in light of the product we maintain would be more than remarkable. Having done that, please endeavour to make an actual contribution to the discussion. Hi Andrew, Let's be fair. It would be an almost impossible task to make any sense of the archives on this topic without dedicating tens of hours to the task, and having access to a better way of reading the archives than is offered at archives.postgresql.org. Raphaël, there have indeed been vast debates about this. My version of the executive summary would be that some people want a tracker, some people think email is good enough, and the people who do want a tracker have different opinions about which tracker would be best for the project. There's a wiki page about the (daunting) set of features which would be required in a tracker to make everybody happy[1]. We are currently experimenting with using a wiki page to organise our queue of patches[2], and there has been some effort to set up a test bugzilla installation[3] but as yet there has been no viable consensus as to adopting a particular tracker. Cheers, BJ [1] http://wiki.postgresql.org/wiki/TrackerDiscussion [2] http://wiki.postgresql.org/wiki/CommitFest:May [3] http://wiki.postgresql.org/wiki/Tracker:BugzillaTest -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: http://getfiregpg.org iD8DBQFIEsya5YBsbHkuyV0RAnOyAKDI7Ygcb8m689IJtMcGQtmMq+5CPwCeMIsk /+eXsTtGNVVWIfsvNsEyW7A= =6DTB -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Tech details - psql wraps at window width
-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 that wrapped is more a variant of aligned mode than a format mode in its own right. Expressing it that way with \pset has the nice bonus that you don't lose your preference for wrapped mode when switching between aligned and unaligned with \a. But there's still the issue of wanting separate defaults for tty and stream outputs. The last thing you want is an admin deciding on wrapping, and then subtly breaking scripts. My personal desired defaults are: Well, if we pursue Peter's suggestion that psql abstain from reading the startup file in noninteractive mode, then this problem goes away. An admin could opt to wrap in his interactive sessions without it ever affecting the behaviour of scripts ... which is exactly what you would want. Cheers, BJ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: http://getfiregpg.org iD8DBQFIEs3x5YBsbHkuyV0RAiPsAJ0QIhWmq4s622dTZNP4MknxWTm30wCfaMTP kY9qEW0GB3rJb3Xq5F92geY= =GbOb -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] MERGE Specification
Simon Riggs wrote: 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 UPDATEs do not work on views? Yes, that's right. Just like COPY. That seems fine to me because you're likely to be doing a MERGE immediately after a COPY anyway, so the restriction just continues. May be the bulk data merging variant of MERGE to be used after initial COPY should be a variant of COPY with special keyword(s) instead of MERGE ? That does sound like a good way of differentiating between the OLTP and bulk loading cases. I'll bear that in mind as we develop. To me, a simple user, it'd be important that MERGE implementation does not place any unpredictable restrictions. For example in Oracle you can break any MERGE statement by placing a full text index on the table. So I'd really expect a MERGE in PostgreSQL to be fine with views, rules, tsearch, etc. Just my 2 cent. -- Best regards, Hannes Dorbath -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Tech details - psql wraps at window width
Bruce Momjian wrote: Hey, I can work with this idea. First, there really is no 'off' mode for wrapped because that is aligned. What we could do is to have: \pset format wrapped display affect only output to the screen, using the screen width, and: \pset format wrapped nnn affect output to the screen and file/pipes. A new idea would be for a wrap value of zero to be special: \pset format wrapped 0 to wrap to screen width for terminal and file/pipe output. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposed patch - psql wraps at window width
Bruce Momjian wrote: Gregory Stark wrote: I don't see that behavior here on Ubuntu 7.10: $ COLUMNNS=120 ls -C |cat archive cdinitrd lost+found proc srv usr basement.usr dev initrd.img media root sys var bin etc laptop mnt rtmp tmp vmlinuz boot home lib opt sbin uwin $ ls --version ls (GNU coreutils) 5.97 That is not a 120 width. 'ls' seems to ignore columns for pipe output. Oops, Alvaro pointed out I typo'ed the variable name COLUMNS as COLUMNNS. I see now that 'ls -C' does honor columns. See my later posting about '\pset wrapped 0' as a special case where we could honor the ioctl/COLUMNS case. My real confusion is this: $ echo $COLUMNS 146 $ ls -C|less archive cdinitrd lost+found proc srv usr basement.usr dev initrd.img media root sys var bin etc laptop mnt rtmp tmp vmlinuz boot home lib opt sbin uwin $ COLUMNS=120 ls -C|less archive bin cd etc initrd laptop lost+found mnt proc rtmp srv tmp usr vmlinuz basement.usr boot dev home initrd.img lib media opt root sbin sys uvar win Why does the first 'ls' not honor columns while the second does? How does 'ls' detect that the COLUMNS=120 is somehow different from the default COLUMNS value? -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Update: * Allow adding enumerated values to an existing
Andrew Dunstan escribió: 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 rewrite, but they'll have to get fairly busy to do it. Rewrite would be required for reorderings. Or else we just error out in such cases. As Tom Lane suggests, rewriting has some nasty deadlock possibilities. You always have the option of creating a new enum type and moving each affected column to that type. Another alternative would be internally creating a different temporary enum, rewriting the tables one by one each on its own transaction, and finish by dropping the original enum and renaming the temporary one. This solves the deadlock problem. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposed patch - psql wraps at window width
* Bruce Momjian [EMAIL PROTECTED] [080426 09:44]: Why does the first 'ls' not honor columns while the second does? How does 'ls' detect that the COLUMNS=120 is somehow different from the default COLUMNS value? I would hazard a guess that COLUMNS isn't exported from your shell environment in the first case. In the other cases, the explicit: VAR=... command the shell is told to set VAR explicitly before starting command, in addition to any exported vars. a. -- Aidan Van Dyk Create like a god, [EMAIL PROTECTED] command like a king, http://www.highrise.ca/ work like a slave. signature.asc Description: Digital signature
Re: [HACKERS] Proposed patch - psql wraps at window width
Bruce Momjian wrote:
Oops, Alvaro pointed out I typo'ed the variable name COLUMNS as
COLUMNNS. I see now that 'ls -C' does honor columns. See my later
posting about '\pset wrapped 0' as a special case where we could honor
the ioctl/COLUMNS case.
My real confusion is this:
$ echo $COLUMNS
146
$ ls -C|less
archive cdinitrd lost+found proc srv usr
basement.usr dev initrd.img media root sys var
bin etc laptop mnt rtmp tmp vmlinuz
boot home lib opt sbin uwin
$ COLUMNS=120 ls -C|less
archive bin cd etc initrd laptop lost+found mnt
proc rtmp srv tmp usr vmlinuz
basement.usr boot dev home initrd.img lib media opt
root sbin sys uvar win
Why does the first 'ls' not honor columns while the second does? How
does 'ls' detect that the COLUMNS=120 is somehow different from the
default COLUMNS value?
Ah, I see now. $COLUMNS isn't exported to subshells, hence the previous
comment that readline needs to be called before it has a value. It
seems psql does have COLUMNS set if readline is defined, which means we
can't detect of $COLUMNS was passed to psql or was detected. More
interesting, it doesn't seem psql sets $COLUMNS in batch mode:
psql -c '\echo `echo $COLUMNS`' test
{blank line}
COLUMNS=120 sql -c '\echo `echo $COLUMNS`' test
120
so we could argue that COLUMNS should be honored but again this would
affect \g filename. The issue with 'ls' is that it knows it isn't going
to be getting new commands from the user that change where its output is
going, while psql can.
--
Bruce Momjian [EMAIL PROTECTED]http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] FSM fill ratio
Jacques Caron wrote: 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 xxx?) This would help a lot finding out whether the current fsm settings are fine or not... There's contrib/pg_freespacemap -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposed patch - psql wraps at window width
Gregory Stark wrote: [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 that succeeds, if it fails it uses COLUMNS, and if that's unavailable it uses a constant. $ COLUMNS=40 ls -C | cat distmp3.rh3280 purpleNMN49T gconfd-starkssh-WdHPsk4277 orbit-stark I don't see that behavior here on Ubuntu 7.10: $ COLUMNNS=120 ls -C |cat archive cdinitrd lost+found proc srv usr basement.usr dev initrd.img media root sys var bin etc laptop mnt rtmp tmp vmlinuz boot home lib opt sbin uwin $ ls --version ls (GNU coreutils) 5.97 That is not a 120 width. 'ls' seems to ignore columns for pipe output. That might make the I want it always to wrap group happier, but not the wrapped shouldn't affect file/pipe. I have not heard anyone explain why the later behavior is bad, especially if we default to a width of 72 rather than the screen width. Presumably they're concerned that scripts which dump out data and then try to parse it will have trouble parsing wrapped output. In any case that should be based on whether isatty() is true, which is related to but not the same as whether the window size ioctl succeeds. Right now we honor $COLUMNS only when isatty() is true. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] we don't have a bugzilla
Brendan Jurd wrote: Having done that, please endeavour to make an actual contribution to the discussion. Hi Andrew, Let's be fair. It would be an almost impossible task to make any sense of the archives on this topic without dedicating tens of hours to the task, and having access to a better way of reading the archives than is offered at archives.postgresql.org. +1 The idea that anyone would waste their time (and yes it is a complete waste of time) reviewing the archives which are almost impossible to search unless you know exactly what you are looking for is ridiculous. Andrew, I am frankly surprised that you would have that response for the individual. How do you know he was trolling? Perhaps he is just surprised (which is the impression that I got) that considering we are such a mature project that we don't have a bugzilla or other such beast. Sincerely, Joshua D. Drake -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Update: * Allow adding enumerated values to an existing
Alvaro Herrera wrote: Andrew Dunstan escribió: 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 rewrite, but they'll have to get fairly busy to do it. Rewrite would be required for reorderings. Or else we just error out in such cases. As Tom Lane suggests, rewriting has some nasty deadlock possibilities. You always have the option of creating a new enum type and moving each affected column to that type. Another alternative would be internally creating a different temporary enum, rewriting the tables one by one each on its own transaction, and finish by dropping the original enum and renaming the temporary one. This solves the deadlock problem. What happens when someone tries to join two of the tables, one that has been converted and one that hasn't? You might not have deadlock, but you won't have type integrity either, ISTM. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] we don't have a bugzilla
Joshua D. Drake wrote: Brendan Jurd wrote: Having done that, please endeavour to make an actual contribution to the discussion. Hi Andrew, Let's be fair. It would be an almost impossible task to make any sense of the archives on this topic without dedicating tens of hours to the task, and having access to a better way of reading the archives than is offered at archives.postgresql.org. +1 The idea that anyone would waste their time (and yes it is a complete waste of time) reviewing the archives which are almost impossible to search unless you know exactly what you are looking for is ridiculous. Andrew, I am frankly surprised that you would have that response for the individual. I entered bugzilla on the archives search page and got this link, right out of the recent discussion, at the top of the list: http://archives.postgresql.org/pgsql-hackers/2008-04/msg00764.php That and a few similar results might have given the OP some hints about what people are thinking and why. So your suggestion that the search engine is useless is just plain wrong in this case. How do you know he was trolling? Perhaps he is just surprised (which is the impression that I got) that considering we are such a mature project that we don't have a bugzilla or other such beast. Well, his post added precisely nothing to the debate. Personally, when I find something surprising my first reaction is to go looking for a reason, and only to ask about it if I can't find answers. As I have demonstrated, finding clues would have been absurdly simple, despite your assertion to the contrary. I just don't see any point at all in posting a link to some random blog where mostly anonymous posters comment on our lack of a bug tracker. A reasoned contribution to the debate on the other hand will be welcome. Perhaps it wasn't a troll. If it wasn't I apologise. My other points remain, however. (BTW, I have long been on the record as being in favor of using a tracker for both bugs and features, and I did work some years ago on making mainline Bugzilla fully support Postgres.) cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] we don't have a bugzilla
Andrew Dunstan wrote: I entered bugzilla on the archives search page and got this link, right out of the recent discussion, at the top of the list: http://archives.postgresql.org/pgsql-hackers/2008-04/msg00764.php That and a few similar results might have given the OP some hints about what people are thinking and why. How would he know to search at the archives? * There is no archives signature at the bottom of -hackers lists * The mail-pref link when followed doesn't provide a link to the archives * The website? Hmm I guess I click support and then a link called mailing lists, oh and then there is a link somewhere down the middle of the page that says, archives. Lastly, why would I search the archives? There is this vast assumption that anyone (I do this too) will just know to do something in this community. I think that assumption is far off base. IMO, a more appropriate response would have been something like: Thanks for the discussion, this is something our community is currently considering. You can view these two links if you are interested. link link All we did with our response is say... Hey, you are a troll, go away. When in fact he likely wasn't. Well, his post added precisely nothing to the debate. Personally, when I find something surprising my first reaction is to go looking for a reason, and only to ask about it if I can't find answers. As I have As my wife often tells me, you are not like everyone else. The first natural response from most people that I encounter, is to ask not to research. demonstrated, finding clues would have been absurdly simple, despite your assertion to the contrary. I just don't see any point at all in posting a link to some random blog where mostly anonymous posters comment on our lack of a bug tracker. Well I won't disagree that the post was offtopic for the list. (BTW, I have long been on the record as being in favor of using a tracker for both bugs and features, and I did work some years ago on making mainline Bugzilla fully support Postgres.) Right, which is also why I was surprised by your reply. Sincerely, Joshua D. Drake -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposed patch - psql wraps at window width
Bruce Momjian [EMAIL PROTECTED] writes: I don't see that behavior here on Ubuntu 7.10: $ COLUMNNS=120 ls -C |cat archive cdinitrd lost+found proc srv usr basement.usr dev initrd.img media root sys var bin etc laptop mnt rtmp tmp vmlinuz boot home lib opt sbin uwin $ ls --version ls (GNU coreutils) 5.97 That is not a 120 width. 'ls' seems to ignore columns for pipe output. Well, it's *certainly* gonna ignore COLUMNNS. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Update: * Allow adding enumerated values to an existing
Andrew Dunstan [EMAIL PROTECTED] writes: Alvaro Herrera wrote: Another alternative would be internally creating a different temporary enum, rewriting the tables one by one each on its own transaction, and finish by dropping the original enum and renaming the temporary one. This solves the deadlock problem. What happens when someone tries to join two of the tables, one that has been converted and one that hasn't? You might not have deadlock, but you won't have type integrity either, ISTM. Not to mention the mess you'll be left with if the process fails after converting some of the tables. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] we don't have a bugzilla
Joshua D. Drake [EMAIL PROTECTED] writes: How would he know to search at the archives? If he knew enough about the community to post in -hackers (as opposed to, say, -general or -novice) he should certainly have heard of the mailing list archives. *You* might find 'em useless but I don't. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] we don't have a bugzilla
Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: How would he know to search at the archives? If he knew enough about the community to post in -hackers (as opposed to, say, -general or -novice) he should certainly have heard of the You think so? (not being sarcastic). mailing list archives. *You* might find 'em useless but I don't. I didn't say I found them useless. I said they are useless unless you know what you are looking for. I am pretty sure that when it comes to PostgreSQL, you always know what you are looking for. Anyway, now I am off-topic, so I am done with this thread. Sincerely, Joshua D. Drake -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Traveling this week
I am leaving tomorrow/Sunday for a one-week trip for EnterpriseDB to Mineapolis and Los Angeles. I will be offline most of the trip so I will miss the start of the May commit fest. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] we don't have a bugzilla
On Sat, Apr 26, 2008 at 08:54:46AM -0700, Joshua D. Drake wrote: How would he know to search at the archives? * There is no archives signature at the bottom of -hackers lists Maybe because there's a perfectly functional archive link in the mail headers? And because there's an RFC that tells us how such headers are supposed to work? A -- Andrew Sullivan [EMAIL PROTECTED] +1 503 667 4564 x104 http://www.commandprompt.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
